GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
oesa-2026-1231
Vulnerability from osv_openeuler
Published
2026-01-23 11:10
Modified
2026-08-06 11:10
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

scsi: libsas: Fix use-after-free bug in smp_execute_task_sg()

When executing SMP task failed, the smp_execute_task_sg() calls del_timer() to delete "slow_task->timer". However, if the timer handler sas_task_internal_timedout() is running, the del_timer() in smp_execute_task_sg() will not stop it and a UAF will happen. The process is shown below:

  (thread 1)               |        (thread 2)

smp_execute_task_sg() | sas_task_internal_timedout() ... | del_timer() | ... | ... sas_free_task(task) | kfree(task->slow_task) //FREE| | task->slow_task->... //USE

Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure the timer handler have finished before the "task->slow_task" is deallocated.(CVE-2022-50422)

In the Linux kernel, the following vulnerability has been resolved:

ppp: associate skb with a device at tx

Syzkaller triggered flow dissector warning with the following:

r0 = openat$ppp(0xffffffffffffff9c, &(0x7f0000000000), 0xc0802, 0x0) ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &(0x7f00000000c0)) ioctl$PPPIOCSACTIVE(r0, 0x40107446, &(0x7f0000000240)={0x2, &(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]}) pwritev(r0, &(0x7f0000000040)=[{&(0x7f0000000140)='\x00!', 0x2}], 0x1, 0x0, 0x0)

[ 9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0 [ 9.485929] skb_get_poff+0x53/0xa0 [ 9.485937] bpf_skb_get_pay_offset+0xe/0x20 [ 9.485944] ? ppp_send_frame+0xc2/0x5b0 [ 9.485949] ? _raw_spin_unlock_irqrestore+0x40/0x60 [ 9.485958] ? __ppp_xmit_process+0x7a/0xe0 [ 9.485968] ? ppp_xmit_process+0x5b/0xb0 [ 9.485974] ? ppp_write+0x12a/0x190 [ 9.485981] ? do_iter_write+0x18e/0x2d0 [ 9.485987] ? __import_iovec+0x30/0x130 [ 9.485997] ? do_pwritev+0x1b6/0x240 [ 9.486016] ? trace_hardirqs_on+0x47/0x50 [ 9.486023] ? __x64_sys_pwritev+0x24/0x30 [ 9.486026] ? do_syscall_64+0x3d/0x80 [ 9.486031] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd

Flow dissector tries to find skb net namespace either via device or via socket. Neigher is set in ppp_send_frame, so let's manually use ppp->dev.(CVE-2022-50655)

In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Fix "kernel NULL pointer dereference" error

When rxe_queue_init in the function rxe_qp_init_req fails, both qp->req.task.func and qp->req.task.arg are not initialized.

Because of creation of qp fails, the function rxe_create_qp will call rxe_qp_do_cleanup to handle allocated resource.

Before calling __rxe_do_task, both qp->req.task.func and qp->req.task.arg should be checked.(CVE-2022-50671)

In the Linux kernel, the following vulnerability has been resolved:

usb: idmouse: fix an uninit-value in idmouse_open

In idmouse_create_image, if any ftip_command fails, it will go to the reset label. However, this leads to the data in bulk_in_buffer[HEADER..IMGSIZE] uninitialized. And the check for valid image incurs an uninitialized dereference.

Fix this by moving the check before reset label since this check only be valid if the data after bulk_in_buffer[HEADER] has concrete data.

Note that this is found by KMSAN, so only kernel compilation is tested.(CVE-2022-50733)

In the Linux kernel, the following vulnerability has been resolved:

acct: fix potential integer overflow in encode_comp_t()

The integer overflow is descripted with following codes: > 317 static comp_t encode_comp_t(u64 value) > 318 { > 319 int exp, rnd; ...... > 341 exp <<= MANTSIZE; > 342 exp += value; > 343 return exp; > 344 }

Currently comp_t is defined as type of '__u16', but the variable 'exp' is type of 'int', so overflow would happen when variable 'exp' in line 343 is greater than 65535.(CVE-2022-50749)

In the Linux kernel, the following vulnerability has been resolved:

udf: Avoid double brelse() in udf_rename()

syzbot reported a warning like below 1:

VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0 ... Call Trace: <TASK> invalidate_bh_lru+0x99/0x150 smp_call_function_many_cond+0xe2a/0x10c0 ? generic_remap_file_range_prep+0x50/0x50 ? __brelse+0xa0/0xa0 ? __mutex_lock+0x21c/0x12d0 ? smp_call_on_cpu+0x250/0x250 ? rcu_read_lock_sched_held+0xb/0x60 ? lock_release+0x587/0x810 ? __brelse+0xa0/0xa0 ? generic_remap_file_range_prep+0x50/0x50 on_each_cpu_cond_mask+0x3c/0x80 blkdev_flush_mapping+0x13a/0x2f0 blkdev_put_whole+0xd3/0xf0 blkdev_put+0x222/0x760 deactivate_locked_super+0x96/0x160 deactivate_super+0xda/0x100 cleanup_mnt+0x222/0x3d0 task_work_run+0x149/0x240 ? task_work_cancel+0x30/0x30 do_exit+0xb29/0x2a40 ? reacquire_held_locks+0x4a0/0x4a0 ? do_raw_spin_lock+0x12a/0x2b0 ? mm_update_next_owner+0x7c0/0x7c0 ? rwlock_bug.part.0+0x90/0x90 ? zap_other_threads+0x234/0x2d0 do_group_exit+0xd0/0x2a0 __x64_sys_exit_group+0x3a/0x50 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd

The cause of the issue is that brelse() is called on both ofibh.sbh and ofibh.ebh by udf_find_entry() when it returns NULL. However, brelse() is called by udf_rename(), too. So, b_count on buffer_head becomes unbalanced.

This patch fixes the issue by not calling brelse() by udf_rename() when udf_find_entry() returns NULL.(CVE-2022-50755)

In the Linux kernel, the following vulnerability has been resolved:

drm: Prevent drm_copy_field() to attempt copying a NULL pointer

There are some struct drm_driver fields that are required by drivers since drm_copy_field() attempts to copy them to user-space via DRM_IOCTL_VERSION.

But it can be possible that a driver has a bug and did not set some of the fields, which leads to drm_copy_field() attempting to copy a NULL pointer:

[ +10.395966] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000 [ +0.010955] Mem abort info: [ +0.002835] ESR = 0x0000000096000004 [ +0.003872] EC = 0x25: DABT (current EL), IL = 32 bits [ +0.005395] SET = 0, FnV = 0 [ +0.003113] EA = 0, S1PTW = 0 [ +0.003182] FSC = 0x04: level 0 translation fault [ +0.004964] Data abort info: [ +0.002919] ISV = 0, ISS = 0x00000004 [ +0.003886] CM = 0, WnR = 0 [ +0.003040] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000115dad000 [ +0.006536] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ +0.006925] Internal error: Oops: 96000004 [#1] SMP ... [ +0.011113] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ +0.007061] pc : __pi_strlen+0x14/0x150 [ +0.003895] lr : drm_copy_field+0x30/0x1a4 [ +0.004156] sp : ffff8000094b3a50 [ +0.003355] x29: ffff8000094b3a50 x28: ffff8000094b3b70 x27: 0000000000000040 [ +0.007242] x26: ffff443743c2ba00 x25: 0000000000000000 x24: 0000000000000040 [ +0.007243] x23: ffff443743c2ba00 x22: ffff8000094b3b70 x21: 0000000000000000 [ +0.007241] x20: 0000000000000000 x19: ffff8000094b3b90 x18: 0000000000000000 [ +0.007241] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab14b9af40 [ +0.007241] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ +0.007239] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa524ad67d4d8 [ +0.007242] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : 6c6e6263606e7141 [ +0.007239] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ +0.007241] x2 : 0000000000000000 x1 : ffff8000094b3b90 x0 : 0000000000000000 [ +0.007240] Call trace: [ +0.002475] __pi_strlen+0x14/0x150 [ +0.003537] drm_version+0x84/0xac [ +0.003448] drm_ioctl_kernel+0xa8/0x16c [ +0.003975] drm_ioctl+0x270/0x580 [ +0.003448] __arm64_sys_ioctl+0xb8/0xfc [ +0.003978] invoke_syscall+0x78/0x100 [ +0.003799] el0_svc_common.constprop.0+0x4c/0xf4 [ +0.004767] do_el0_svc+0x38/0x4c [ +0.003357] el0_svc+0x34/0x100 [ +0.003185] el0t_64_sync_handler+0x11c/0x150 [ +0.004418] el0t_64_sync+0x190/0x194 [ +0.003716] Code: 92402c04 b200c3e8 f13fc09f 5400088c (a9400c02) [ +0.006180] ---[ end trace 0000000000000000 ]---(CVE-2022-50884)

In the Linux kernel, the following vulnerability has been resolved:

crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()

During NVMeTCP Authentication a controller can trigger a kernel oops by specifying the 8192 bit Diffie Hellman group and passing a correctly sized, but zeroed Diffie Hellamn value. mpi_cmp_ui() was detecting this if the second parameter was 0, but 1 is passed from dh_is_pubkey_valid(). This causes the null pointer u->d to be dereferenced towards the end of mpi_cmp_ui()(CVE-2023-53817)

In the Linux kernel, the following vulnerability has been resolved:

ip6_vti: fix slab-use-after-free in decode_session6

When ipv6_vti device is set to the qdisc of the sfb type, the cb field of the sent skb may be modified during enqueuing. Then, slab-use-after-free may occur when ipv6_vti device sends IPv6 packets.

The stack information is as follows: BUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890 Read of size 1 at addr ffff88802e08edc2 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0-next-20230707-00001-g84e2cad7f979 #410 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0xd9/0x150 print_address_description.constprop.0+0x2c/0x3c0 kasan_report+0x11d/0x130 decode_session6+0x103f/0x1890 __xfrm_decode_session+0x54/0xb0 vti6_tnl_xmit+0x3e6/0x1ee0 dev_hard_start_xmit+0x187/0x700 sch_direct_xmit+0x1a3/0xc30 __qdisc_run+0x510/0x17a0 __dev_queue_xmit+0x2215/0x3b10 neigh_connected_output+0x3c2/0x550 ip6_finish_output2+0x55a/0x1550 ip6_finish_output+0x6b9/0x1270 ip6_output+0x1f1/0x540 ndisc_send_skb+0xa63/0x1890 ndisc_send_rs+0x132/0x6f0 addrconf_rs_timer+0x3f1/0x870 call_timer_fn+0x1a0/0x580 expire_timers+0x29b/0x4b0 run_timer_softirq+0x326/0x910 __do_softirq+0x1d4/0x905 irq_exit_rcu+0xb7/0x120 sysvec_apic_timer_interrupt+0x97/0xc0 </IRQ> Allocated by task 9176: kasan_save_stack+0x22/0x40 kasan_set_track+0x25/0x30 __kasan_slab_alloc+0x7f/0x90 kmem_cache_alloc_node+0x1cd/0x410 kmalloc_reserve+0x165/0x270 __alloc_skb+0x129/0x330 netlink_sendmsg+0x9b1/0xe30 sock_sendmsg+0xde/0x190 _syssendmsg+0x739/0x920 _sys_sendmsg+0x110/0x1b0 __sys_sendmsg+0xf7/0x1c0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 9176: kasan_save_stack+0x22/0x40 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x40 _kasanslab_free+0x160/0x1c0 slab_free_freelist_hook+0x11b/0x220 kmem_cache_free+0xf0/0x490 skb_free_head+0x17f/0x1b0 skb_release_data+0x59c/0x850 consume_skb+0xd2/0x170 netlink_unicast+0x54f/0x7f0 netlink_sendmsg+0x926/0xe30 sock_sendmsg+0xde/0x190 __sys_sendmsg+0x739/0x920 syssendmsg+0x110/0x1b0 sys_sendmsg+0xf7/0x1c0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The buggy address belongs to the object at ffff88802e08ed00 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 194 bytes inside of freed 640-byte region [ffff88802e08ed00, ffff88802e08ef80)

As commit f855691975bb ("xfrm6: Fix the nexthdr offset in _decode_session6.") showed, xfrm_decode_session was originally intended only for the receive path. IP6CB(skb)->nhoff is not set during transmission. Therefore, set the cb field in the skb to 0 before sending packets.(CVE-2023-53821)

In the Linux kernel, the following vulnerability has been resolved:

ubi: Fix UAF wear-leveling entry in eraseblk_count_seq_show()

Wear-leveling entry could be freed in error path, which may be accessed again in eraseblk_count_seq_show(), for example:

__erase_worker eraseblk_count_seq_show wl = ubi->lookuptbl[*block_number] if (wl) wl_entry_destroy ubi->lookuptbl[e->pnum] = NULL kmem_cache_free(ubi_wl_entry_slab, e) erase_count = wl->ec // UAF!

Wear-leveling entry updating/accessing in ubi->lookuptbl should be protected by ubi->wl_lock, fix it by adding ubi->wl_lock to serialize wl entry accessing between wl_entry_destroy() and eraseblk_count_seq_show().

Fetch a reproducer in [Link].(CVE-2023-53826)

In the Linux kernel, the following vulnerability has been resolved:

md/raid10: fix null-ptr-deref in raid10_sync_request

init_resync() inits mempool and sets conf->have_replacemnt at the beginning of sync, close_sync() frees the mempool when sync is completed.

After 1 recovery might be skipped and init_resync() is called but close_sync() is not. null-ptr-deref occurs with r10bio->dev[i].repl_bio.

The following is one way to reproduce the issue.

1) create a array, wait for resync to complete, mddev->recovery_cp is set to MaxSector. 2) recovery is woken and it is skipped. conf->have_replacement is set to 0 in init_resync(). close_sync() not called. 3) some io errors and rdev A is set to WantReplacement. 4) a new device is added and set to A's replacement. 5) recovery is woken, A have replacement, but conf->have_replacemnt is 0. r10bio->dev[i].repl_bio will not be alloced and null-ptr-deref occurs.

Fix it by not calling init_resync() if recovery skipped.

1 commit 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled")(CVE-2023-53832)

In the Linux kernel, the following vulnerability has been resolved:

hwrng: virtio - Fix race on data_avail and actual data

The virtio rng device kicks off a new entropy request whenever the data available reaches zero. When a new request occurs at the end of a read operation, that is, when the result of that request is only needed by the next reader, then there is a race between the writing of the new data and the next reader.

This is because there is no synchronisation whatsoever between the writer and the reader.

Fix this by writing data_avail with smp_store_release and reading it with smp_load_acquire when we first enter read. The subsequent reads are safe because they're either protected by the first load acquire, or by the completion mechanism.

Also remove the redundant zeroing of data_idx in random_recv_done (data_idx must already be zero at this point) and data_avail in request_entropy (ditto).(CVE-2023-53998)

In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Check valid rport returned by fc_bsg_to_rport()

Klocwork reported warning of rport maybe NULL and will be dereferenced. rport returned by call to fc_bsg_to_rport() could be NULL and dereferenced.

Check valid rport returned by fc_bsg_to_rport().(CVE-2023-54014)

In the Linux kernel, the following vulnerability has been resolved:

drm/client: Fix memory leak in drm_client_target_cloned

dmt_mode is allocated and never freed in this function. It was found with the ast driver, but most drivers using generic fbdev setup are probably affected.

This fixes the following kmemleak report: backtrace: [<00000000b391296d>] drm_mode_duplicate+0x45/0x220 [drm] [<00000000e45bb5b3>] drm_client_target_cloned.constprop.0+0x27b/0x480 [drm] [<00000000ed2d3a37>] drm_client_modeset_probe+0x6bd/0xf50 [drm] [<0000000010e5cc9d>] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper] [<00000000909f82ca>] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper] [<00000000063a69aa>] drm_client_register+0x169/0x240 [drm] [<00000000a8c61525>] ast_pci_probe+0x142/0x190 [ast] [<00000000987f19bb>] local_pci_probe+0xdc/0x180 [<000000004fca231b>] work_for_cpu_fn+0x4e/0xa0 [<0000000000b85301>] process_one_work+0x8b7/0x1540 [<000000003375b17c>] worker_thread+0x70a/0xed0 [<00000000b0d43cd9>] kthread+0x29f/0x340 [<000000008d770833>] ret_from_fork+0x1f/0x30 unreferenced object 0xff11000333089a00 (size 128):(CVE-2023-54091)

In the Linux kernel, the following vulnerability has been resolved:

md/raid10: fix memleak for 'conf->bio_split'

In the error path of raid10_run(), 'conf' need be freed, however, 'conf->bio_split' is missed and memory will be leaked.

Since there are 3 places to free 'conf', factor out a helper to fix the problem.(CVE-2023-54123)

In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_sdei: Fix sleep from invalid context BUG

Running a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altra triggers:

BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 24, name: cpuhp/0 preempt_count: 0, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by cpuhp/0/24: #0: ffffda30217c70d0 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #1: ffffda30217c7120 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #2: ffffda3021c711f0 (sdei_list_lock){....}-{3:3}, at: sdei_cpuhp_up+0x3c/0x130 irq event stamp: 36 hardirqs last enabled at (35): [<ffffda301e85b7bc>] finish_task_switch+0xb4/0x2b0 hardirqs last disabled at (36): [<ffffda301e812fec>] cpuhp_thread_fun+0x21c/0x248 softirqs last enabled at (0): [<ffffda301e80b184>] copy_process+0x63c/0x1ac0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 0 PID: 24 Comm: cpuhp/0 Not tainted 5.19.0-rc3-rt5-[...] Hardware name: WIWYNN Mt.Jade Server [...] Call trace: dump_backtrace+0x114/0x120 show_stack+0x20/0x70 dump_stack_lvl+0x9c/0xd8 dump_stack+0x18/0x34 __might_resched+0x188/0x228 rt_spin_lock+0x70/0x120 sdei_cpuhp_up+0x3c/0x130 cpuhp_invoke_callback+0x250/0xf08 cpuhp_thread_fun+0x120/0x248 smpboot_thread_fn+0x280/0x320 kthread+0x130/0x140 ret_from_fork+0x10/0x20

sdei_cpuhp_up() is called in the STARTING hotplug section, which runs with interrupts disabled. Use a CPUHP_AP_ONLINE_DYN entry instead to execute the cpuhp cb later, with preemption enabled.

SDEI originally got its own cpuhp slot to allow interacting with perf. It got superseded by pNMI and this early slot is not relevant anymore. 1

Some SDEI calls (e.g. SDEI_1_0_FN_SDEI_PE_MASK) take actions on the calling CPU. It is checked that preemption is disabled for them. _ONLINE cpuhp cb are executed in the 'per CPU hotplug thread'. Preemption is enabled in those threads, but their cpumask is limited to 1 CPU. Move 'WARN_ON_ONCE(preemptible())' statements so that SDEI cpuhp cb don't trigger them.

Also add a check for the SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI call which acts on the calling CPU.

In the Linux kernel, the following vulnerability has been resolved:

fbdev: bitblit: bound-check glyph index in bit_putcs*

bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address.

This fixes a global out-of-bounds read reported by syzbot.(CVE-2025-40322)

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2601.4.0.0359.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2601.4.0.0359.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2601.4.0.0359.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2601.4.0.0359.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: libsas: Fix use-after-free bug in smp_execute_task_sg()\n\nWhen executing SMP task failed, the smp_execute_task_sg() calls del_timer()\nto delete \u0026quot;slow_task-\u0026gt;timer\u0026quot;. However, if the timer handler\nsas_task_internal_timedout() is running, the del_timer() in\nsmp_execute_task_sg() will not stop it and a UAF will happen. The process\nis shown below:\n\n      (thread 1)               |        (thread 2)\nsmp_execute_task_sg()          | sas_task_internal_timedout()\n ...                           |\n del_timer()                   |\n ...                           |  ...\n sas_free_task(task)           |\n  kfree(task-\u0026gt;slow_task) //FREE|\n                               |  task-\u0026gt;slow_task-\u0026gt;... //USE\n\nFix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure\nthe timer handler have finished before the \u0026quot;task-\u0026gt;slow_task\u0026quot; is\ndeallocated.(CVE-2022-50422)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: associate skb with a device at tx\n\nSyzkaller triggered flow dissector warning with the following:\n\nr0 = openat$ppp(0xffffffffffffff9c, \u0026amp;(0x7f0000000000), 0xc0802, 0x0)\nioctl$PPPIOCNEWUNIT(r0, 0xc004743e, \u0026amp;(0x7f00000000c0))\nioctl$PPPIOCSACTIVE(r0, 0x40107446, \u0026amp;(0x7f0000000240)={0x2, \u0026amp;(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})\npwritev(r0, \u0026amp;(0x7f0000000040)=[{\u0026amp;(0x7f0000000140)=\u0026apos;\\x00!\u0026apos;, 0x2}], 0x1, 0x0, 0x0)\n\n[    9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0\n[    9.485929]  skb_get_poff+0x53/0xa0\n[    9.485937]  bpf_skb_get_pay_offset+0xe/0x20\n[    9.485944]  ? ppp_send_frame+0xc2/0x5b0\n[    9.485949]  ? _raw_spin_unlock_irqrestore+0x40/0x60\n[    9.485958]  ? __ppp_xmit_process+0x7a/0xe0\n[    9.485968]  ? ppp_xmit_process+0x5b/0xb0\n[    9.485974]  ? ppp_write+0x12a/0x190\n[    9.485981]  ? do_iter_write+0x18e/0x2d0\n[    9.485987]  ? __import_iovec+0x30/0x130\n[    9.485997]  ? do_pwritev+0x1b6/0x240\n[    9.486016]  ? trace_hardirqs_on+0x47/0x50\n[    9.486023]  ? __x64_sys_pwritev+0x24/0x30\n[    9.486026]  ? do_syscall_64+0x3d/0x80\n[    9.486031]  ? entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nFlow dissector tries to find skb net namespace either via device\nor via socket. Neigher is set in ppp_send_frame, so let\u0026apos;s manually\nuse ppp-\u0026gt;dev.(CVE-2022-50655)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix \u0026quot;kernel NULL pointer dereference\u0026quot; error\n\nWhen rxe_queue_init in the function rxe_qp_init_req fails,\nboth qp-\u0026gt;req.task.func and qp-\u0026gt;req.task.arg are not initialized.\n\nBecause of creation of qp fails, the function rxe_create_qp will\ncall rxe_qp_do_cleanup to handle allocated resource.\n\nBefore calling __rxe_do_task, both qp-\u0026gt;req.task.func and\nqp-\u0026gt;req.task.arg should be checked.(CVE-2022-50671)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: idmouse: fix an uninit-value in idmouse_open\n\nIn idmouse_create_image, if any ftip_command fails, it will\ngo to the reset label. However, this leads to the data in\nbulk_in_buffer[HEADER..IMGSIZE] uninitialized. And the check\nfor valid image incurs an uninitialized dereference.\n\nFix this by moving the check before reset label since this\ncheck only be valid if the data after bulk_in_buffer[HEADER]\nhas concrete data.\n\nNote that this is found by KMSAN, so only kernel compilation\nis tested.(CVE-2022-50733)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nacct: fix potential integer overflow in encode_comp_t()\n\nThe integer overflow is descripted with following codes:\n  \u0026gt; 317 static comp_t encode_comp_t(u64 value)\n  \u0026gt; 318 {\n  \u0026gt; 319         int exp, rnd;\n    ......\n  \u0026gt; 341         exp \u0026lt;\u0026lt;= MANTSIZE;\n  \u0026gt; 342         exp += value;\n  \u0026gt; 343         return exp;\n  \u0026gt; 344 }\n\nCurrently comp_t is defined as type of \u0026apos;__u16\u0026apos;, but the variable \u0026apos;exp\u0026apos; is\ntype of \u0026apos;int\u0026apos;, so overflow would happen when variable \u0026apos;exp\u0026apos; in line 343 is\ngreater than 65535.(CVE-2022-50749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: Avoid double brelse() in udf_rename()\n\nsyzbot reported a warning like below [1]:\n\nVFS: brelse: Trying to free free buffer\nWARNING: CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n invalidate_bh_lru+0x99/0x150\n smp_call_function_many_cond+0xe2a/0x10c0\n ? generic_remap_file_range_prep+0x50/0x50\n ? __brelse+0xa0/0xa0\n ? __mutex_lock+0x21c/0x12d0\n ? smp_call_on_cpu+0x250/0x250\n ? rcu_read_lock_sched_held+0xb/0x60\n ? lock_release+0x587/0x810\n ? __brelse+0xa0/0xa0\n ? generic_remap_file_range_prep+0x50/0x50\n on_each_cpu_cond_mask+0x3c/0x80\n blkdev_flush_mapping+0x13a/0x2f0\n blkdev_put_whole+0xd3/0xf0\n blkdev_put+0x222/0x760\n deactivate_locked_super+0x96/0x160\n deactivate_super+0xda/0x100\n cleanup_mnt+0x222/0x3d0\n task_work_run+0x149/0x240\n ? task_work_cancel+0x30/0x30\n do_exit+0xb29/0x2a40\n ? reacquire_held_locks+0x4a0/0x4a0\n ? do_raw_spin_lock+0x12a/0x2b0\n ? mm_update_next_owner+0x7c0/0x7c0\n ? rwlock_bug.part.0+0x90/0x90\n ? zap_other_threads+0x234/0x2d0\n do_group_exit+0xd0/0x2a0\n __x64_sys_exit_group+0x3a/0x50\n do_syscall_64+0x34/0xb0\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe cause of the issue is that brelse() is called on both ofibh.sbh\nand ofibh.ebh by udf_find_entry() when it returns NULL.  However,\nbrelse() is called by udf_rename(), too.  So, b_count on buffer_head\nbecomes unbalanced.\n\nThis patch fixes the issue by not calling brelse() by udf_rename()\nwhen udf_find_entry() returns NULL.(CVE-2022-50755)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm: Prevent drm_copy_field() to attempt copying a NULL pointer\n\nThere are some struct drm_driver fields that are required by drivers since\ndrm_copy_field() attempts to copy them to user-space via DRM_IOCTL_VERSION.\n\nBut it can be possible that a driver has a bug and did not set some of the\nfields, which leads to drm_copy_field() attempting to copy a NULL pointer:\n\n[ +10.395966] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000\n[  +0.010955] Mem abort info:\n[  +0.002835]   ESR = 0x0000000096000004\n[  +0.003872]   EC = 0x25: DABT (current EL), IL = 32 bits\n[  +0.005395]   SET = 0, FnV = 0\n[  +0.003113]   EA = 0, S1PTW = 0\n[  +0.003182]   FSC = 0x04: level 0 translation fault\n[  +0.004964] Data abort info:\n[  +0.002919]   ISV = 0, ISS = 0x00000004\n[  +0.003886]   CM = 0, WnR = 0\n[  +0.003040] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000115dad000\n[  +0.006536] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n[  +0.006925] Internal error: Oops: 96000004 [#1] SMP\n...\n[  +0.011113] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  +0.007061] pc : __pi_strlen+0x14/0x150\n[  +0.003895] lr : drm_copy_field+0x30/0x1a4\n[  +0.004156] sp : ffff8000094b3a50\n[  +0.003355] x29: ffff8000094b3a50 x28: ffff8000094b3b70 x27: 0000000000000040\n[  +0.007242] x26: ffff443743c2ba00 x25: 0000000000000000 x24: 0000000000000040\n[  +0.007243] x23: ffff443743c2ba00 x22: ffff8000094b3b70 x21: 0000000000000000\n[  +0.007241] x20: 0000000000000000 x19: ffff8000094b3b90 x18: 0000000000000000\n[  +0.007241] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab14b9af40\n[  +0.007241] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n[  +0.007239] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa524ad67d4d8\n[  +0.007242] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : 6c6e6263606e7141\n[  +0.007239] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\n[  +0.007241] x2 : 0000000000000000 x1 : ffff8000094b3b90 x0 : 0000000000000000\n[  +0.007240] Call trace:\n[  +0.002475]  __pi_strlen+0x14/0x150\n[  +0.003537]  drm_version+0x84/0xac\n[  +0.003448]  drm_ioctl_kernel+0xa8/0x16c\n[  +0.003975]  drm_ioctl+0x270/0x580\n[  +0.003448]  __arm64_sys_ioctl+0xb8/0xfc\n[  +0.003978]  invoke_syscall+0x78/0x100\n[  +0.003799]  el0_svc_common.constprop.0+0x4c/0xf4\n[  +0.004767]  do_el0_svc+0x38/0x4c\n[  +0.003357]  el0_svc+0x34/0x100\n[  +0.003185]  el0t_64_sync_handler+0x11c/0x150\n[  +0.004418]  el0t_64_sync+0x190/0x194\n[  +0.003716] Code: 92402c04 b200c3e8 f13fc09f 5400088c (a9400c02)\n[  +0.006180] ---[ end trace 0000000000000000 ]---(CVE-2022-50884)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()\n\nDuring NVMeTCP Authentication a controller can trigger a kernel\noops by specifying the 8192 bit Diffie Hellman group and passing\na correctly sized, but zeroed Diffie Hellamn value.\nmpi_cmp_ui() was detecting this if the second parameter was 0,\nbut 1 is passed from dh_is_pubkey_valid(). This causes the null\npointer u-\u0026gt;d to be dereferenced towards the end of mpi_cmp_ui()(CVE-2023-53817)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6_vti: fix slab-use-after-free in decode_session6\n\nWhen ipv6_vti device is set to the qdisc of the sfb type, the cb field\nof the sent skb may be modified during enqueuing. Then,\nslab-use-after-free may occur when ipv6_vti device sends IPv6 packets.\n\nThe stack information is as follows:\nBUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890\nRead of size 1 at addr ffff88802e08edc2 by task swapper/0/0\nCPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0-next-20230707-00001-g84e2cad7f979 #410\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014\nCall Trace:\n\u0026lt;IRQ\u0026gt;\ndump_stack_lvl+0xd9/0x150\nprint_address_description.constprop.0+0x2c/0x3c0\nkasan_report+0x11d/0x130\ndecode_session6+0x103f/0x1890\n__xfrm_decode_session+0x54/0xb0\nvti6_tnl_xmit+0x3e6/0x1ee0\ndev_hard_start_xmit+0x187/0x700\nsch_direct_xmit+0x1a3/0xc30\n__qdisc_run+0x510/0x17a0\n__dev_queue_xmit+0x2215/0x3b10\nneigh_connected_output+0x3c2/0x550\nip6_finish_output2+0x55a/0x1550\nip6_finish_output+0x6b9/0x1270\nip6_output+0x1f1/0x540\nndisc_send_skb+0xa63/0x1890\nndisc_send_rs+0x132/0x6f0\naddrconf_rs_timer+0x3f1/0x870\ncall_timer_fn+0x1a0/0x580\nexpire_timers+0x29b/0x4b0\nrun_timer_softirq+0x326/0x910\n__do_softirq+0x1d4/0x905\nirq_exit_rcu+0xb7/0x120\nsysvec_apic_timer_interrupt+0x97/0xc0\n\u0026lt;/IRQ\u0026gt;\nAllocated by task 9176:\nkasan_save_stack+0x22/0x40\nkasan_set_track+0x25/0x30\n__kasan_slab_alloc+0x7f/0x90\nkmem_cache_alloc_node+0x1cd/0x410\nkmalloc_reserve+0x165/0x270\n__alloc_skb+0x129/0x330\nnetlink_sendmsg+0x9b1/0xe30\nsock_sendmsg+0xde/0x190\n____sys_sendmsg+0x739/0x920\n___sys_sendmsg+0x110/0x1b0\n__sys_sendmsg+0xf7/0x1c0\ndo_syscall_64+0x39/0xb0\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nFreed by task 9176:\nkasan_save_stack+0x22/0x40\nkasan_set_track+0x25/0x30\nkasan_save_free_info+0x2b/0x40\n____kasan_slab_free+0x160/0x1c0\nslab_free_freelist_hook+0x11b/0x220\nkmem_cache_free+0xf0/0x490\nskb_free_head+0x17f/0x1b0\nskb_release_data+0x59c/0x850\nconsume_skb+0xd2/0x170\nnetlink_unicast+0x54f/0x7f0\nnetlink_sendmsg+0x926/0xe30\nsock_sendmsg+0xde/0x190\n____sys_sendmsg+0x739/0x920\n___sys_sendmsg+0x110/0x1b0\n__sys_sendmsg+0xf7/0x1c0\ndo_syscall_64+0x39/0xb0\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nThe buggy address belongs to the object at ffff88802e08ed00\nwhich belongs to the cache skbuff_small_head of size 640\nThe buggy address is located 194 bytes inside of\nfreed 640-byte region [ffff88802e08ed00, ffff88802e08ef80)\n\nAs commit f855691975bb (\u0026quot;xfrm6: Fix the nexthdr offset in\n_decode_session6.\u0026quot;) showed, xfrm_decode_session was originally intended\nonly for the receive path. IP6CB(skb)-\u0026gt;nhoff is not set during\ntransmission. Therefore, set the cb field in the skb to 0 before\nsending packets.(CVE-2023-53821)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nubi: Fix UAF wear-leveling entry in eraseblk_count_seq_show()\n\nWear-leveling entry could be freed in error path, which may be accessed\nagain in eraseblk_count_seq_show(), for example:\n\n__erase_worker                eraseblk_count_seq_show\n                                wl = ubi-\u0026gt;lookuptbl[*block_number]\n\t\t\t\tif (wl)\n  wl_entry_destroy\n    ubi-\u0026gt;lookuptbl[e-\u0026gt;pnum] = NULL\n    kmem_cache_free(ubi_wl_entry_slab, e)\n\t\t                   erase_count = wl-\u0026gt;ec  // UAF!\n\nWear-leveling entry updating/accessing in ubi-\u0026gt;lookuptbl should be\nprotected by ubi-\u0026gt;wl_lock, fix it by adding ubi-\u0026gt;wl_lock to serialize\nwl entry accessing between wl_entry_destroy() and\neraseblk_count_seq_show().\n\nFetch a reproducer in [Link].(CVE-2023-53826)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: fix null-ptr-deref in raid10_sync_request\n\ninit_resync() inits mempool and sets conf-\u0026gt;have_replacemnt at the beginning\nof sync, close_sync() frees the mempool when sync is completed.\n\nAfter [1] recovery might be skipped and init_resync() is called but\nclose_sync() is not. null-ptr-deref occurs with r10bio-\u0026gt;dev[i].repl_bio.\n\nThe following is one way to reproduce the issue.\n\n  1) create a array, wait for resync to complete, mddev-\u0026gt;recovery_cp is set\n     to MaxSector.\n  2) recovery is woken and it is skipped. conf-\u0026gt;have_replacement is set to\n     0 in init_resync(). close_sync() not called.\n  3) some io errors and rdev A is set to WantReplacement.\n  4) a new device is added and set to A\u0026apos;s replacement.\n  5) recovery is woken, A have replacement, but conf-\u0026gt;have_replacemnt is\n     0. r10bio-\u0026gt;dev[i].repl_bio will not be alloced and null-ptr-deref\n     occurs.\n\nFix it by not calling init_resync() if recovery skipped.\n\n[1] commit 7e83ccbecd60 (\u0026quot;md/raid10: Allow skipping recovery when clean arrays are assembled\u0026quot;)(CVE-2023-53832)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwrng: virtio - Fix race on data_avail and actual data\n\nThe virtio rng device kicks off a new entropy request whenever the\ndata available reaches zero.  When a new request occurs at the end\nof a read operation, that is, when the result of that request is\nonly needed by the next reader, then there is a race between the\nwriting of the new data and the next reader.\n\nThis is because there is no synchronisation whatsoever between the\nwriter and the reader.\n\nFix this by writing data_avail with smp_store_release and reading\nit with smp_load_acquire when we first enter read.  The subsequent\nreads are safe because they\u0026apos;re either protected by the first load\nacquire, or by the completion mechanism.\n\nAlso remove the redundant zeroing of data_idx in random_recv_done\n(data_idx must already be zero at this point) and data_avail in\nrequest_entropy (ditto).(CVE-2023-53998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Check valid rport returned by fc_bsg_to_rport()\n\nKlocwork reported warning of rport maybe NULL and will be dereferenced.\nrport returned by call to fc_bsg_to_rport() could be NULL and dereferenced.\n\nCheck valid rport returned by fc_bsg_to_rport().(CVE-2023-54014)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/client: Fix memory leak in drm_client_target_cloned\n\ndmt_mode is allocated and never freed in this function.\nIt was found with the ast driver, but most drivers using generic fbdev\nsetup are probably affected.\n\nThis fixes the following kmemleak report:\n  backtrace:\n    [\u0026lt;00000000b391296d\u0026gt;] drm_mode_duplicate+0x45/0x220 [drm]\n    [\u0026lt;00000000e45bb5b3\u0026gt;] drm_client_target_cloned.constprop.0+0x27b/0x480 [drm]\n    [\u0026lt;00000000ed2d3a37\u0026gt;] drm_client_modeset_probe+0x6bd/0xf50 [drm]\n    [\u0026lt;0000000010e5cc9d\u0026gt;] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]\n    [\u0026lt;00000000909f82ca\u0026gt;] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]\n    [\u0026lt;00000000063a69aa\u0026gt;] drm_client_register+0x169/0x240 [drm]\n    [\u0026lt;00000000a8c61525\u0026gt;] ast_pci_probe+0x142/0x190 [ast]\n    [\u0026lt;00000000987f19bb\u0026gt;] local_pci_probe+0xdc/0x180\n    [\u0026lt;000000004fca231b\u0026gt;] work_for_cpu_fn+0x4e/0xa0\n    [\u0026lt;0000000000b85301\u0026gt;] process_one_work+0x8b7/0x1540\n    [\u0026lt;000000003375b17c\u0026gt;] worker_thread+0x70a/0xed0\n    [\u0026lt;00000000b0d43cd9\u0026gt;] kthread+0x29f/0x340\n    [\u0026lt;000000008d770833\u0026gt;] ret_from_fork+0x1f/0x30\nunreferenced object 0xff11000333089a00 (size 128):(CVE-2023-54091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: fix memleak for \u0026apos;conf-\u0026gt;bio_split\u0026apos;\n\nIn the error path of raid10_run(), \u0026apos;conf\u0026apos; need be freed, however,\n\u0026apos;conf-\u0026gt;bio_split\u0026apos; is missed and memory will be leaked.\n\nSince there are 3 places to free \u0026apos;conf\u0026apos;, factor out a helper to fix the\nproblem.(CVE-2023-54123)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_sdei: Fix sleep from invalid context BUG\n\nRunning a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altra\ntriggers:\n\n  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46\n  in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 24, name: cpuhp/0\n  preempt_count: 0, expected: 0\n  RCU nest depth: 0, expected: 0\n  3 locks held by cpuhp/0/24:\n    #0: ffffda30217c70d0 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248\n    #1: ffffda30217c7120 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248\n    #2: ffffda3021c711f0 (sdei_list_lock){....}-{3:3}, at: sdei_cpuhp_up+0x3c/0x130\n  irq event stamp: 36\n  hardirqs last  enabled at (35): [\u0026lt;ffffda301e85b7bc\u0026gt;] finish_task_switch+0xb4/0x2b0\n  hardirqs last disabled at (36): [\u0026lt;ffffda301e812fec\u0026gt;] cpuhp_thread_fun+0x21c/0x248\n  softirqs last  enabled at (0): [\u0026lt;ffffda301e80b184\u0026gt;] copy_process+0x63c/0x1ac0\n  softirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n  CPU: 0 PID: 24 Comm: cpuhp/0 Not tainted 5.19.0-rc3-rt5-[...]\n  Hardware name: WIWYNN Mt.Jade Server [...]\n  Call trace:\n    dump_backtrace+0x114/0x120\n    show_stack+0x20/0x70\n    dump_stack_lvl+0x9c/0xd8\n    dump_stack+0x18/0x34\n    __might_resched+0x188/0x228\n    rt_spin_lock+0x70/0x120\n    sdei_cpuhp_up+0x3c/0x130\n    cpuhp_invoke_callback+0x250/0xf08\n    cpuhp_thread_fun+0x120/0x248\n    smpboot_thread_fn+0x280/0x320\n    kthread+0x130/0x140\n    ret_from_fork+0x10/0x20\n\nsdei_cpuhp_up() is called in the STARTING hotplug section,\nwhich runs with interrupts disabled. Use a CPUHP_AP_ONLINE_DYN entry\ninstead to execute the cpuhp cb later, with preemption enabled.\n\nSDEI originally got its own cpuhp slot to allow interacting\nwith perf. It got superseded by pNMI and this early slot is not\nrelevant anymore. [1]\n\nSome SDEI calls (e.g. SDEI_1_0_FN_SDEI_PE_MASK) take actions on the\ncalling CPU. It is checked that preemption is disabled for them.\n_ONLINE cpuhp cb are executed in the \u0026apos;per CPU hotplug thread\u0026apos;.\nPreemption is enabled in those threads, but their cpumask is limited\nto 1 CPU.\nMove \u0026apos;WARN_ON_ONCE(preemptible())\u0026apos; statements so that SDEI cpuhp cb\ndon\u0026apos;t trigger them.\n\nAlso add a check for the SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI call\nwhich acts on the calling CPU.\n\n[1]:\nhttps://lore.kernel.org/all/(CVE-2023-54160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: bitblit: bound-check glyph index in bit_putcs*\n\nbit_putcs_aligned()/unaligned() derived the glyph pointer from the\ncharacter value masked by 0xff/0x1ff, which may exceed the actual font\u0026apos;s\nglyph count and read past the end of the built-in font array.\nClamp the index to the actual glyph count before computing the address.\n\nThis fixes a global out-of-bounds read reported by syzbot.(CVE-2025-40322)",
  "id": "OESA-2026-1231",
  "modified": "2026-08-06T11:10:15Z",
  "published": "2026-01-23T11:10:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1231"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50422"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50655"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50671"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50733"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50749"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50755"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50884"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53817"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53821"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53826"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53832"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53998"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54014"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54091"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54123"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54160"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40322"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-50422",
    "CVE-2022-50655",
    "CVE-2022-50671",
    "CVE-2022-50733",
    "CVE-2022-50749",
    "CVE-2022-50755",
    "CVE-2022-50884",
    "CVE-2023-53817",
    "CVE-2023-53821",
    "CVE-2023-53826",
    "CVE-2023-53832",
    "CVE-2023-53998",
    "CVE-2023-54014",
    "CVE-2023-54091",
    "CVE-2023-54123",
    "CVE-2023-54160",
    "CVE-2025-40322"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.