{"schema_version":"1.7.2","id":"OESA-2026-1231","modified":"2026-01-23T12:24:04Z","published":"2026-01-23T12:24:04Z","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"],"summary":"kernel security update","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 "slow_task->timer". 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->slow_task) //FREE|\n                               |  task->slow_task->... //USE\n\nFix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure\nthe timer handler have finished before the "task->slow_task" 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, &(0x7f0000000000), 0xc0802, 0x0)\nioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &(0x7f00000000c0))\nioctl$PPPIOCSACTIVE(r0, 0x40107446, &(0x7f0000000240)={0x2, &(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})\npwritev(r0, &(0x7f0000000040)=[{&(0x7f0000000140)='\\x00!', 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's manually\nuse ppp->dev.(CVE-2022-50655)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix "kernel NULL pointer dereference" error\n\nWhen rxe_queue_init in the function rxe_qp_init_req fails,\nboth qp->req.task.func and qp->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->req.task.func and\nqp->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  > 317 static comp_t encode_comp_t(u64 value)\n  > 318 {\n  > 319         int exp, rnd;\n    ......\n  > 341         exp <<= MANTSIZE;\n  > 342         exp += value;\n  > 343         return exp;\n  > 344 }\n\nCurrently comp_t is defined as type of '__u16', but the variable 'exp' is\ntype of 'int', so overflow would happen when variable 'exp' 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 <TASK>\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->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<IRQ>\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</IRQ>\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 ("xfrm6: Fix the nexthdr offset in\n_decode_session6.") showed, xfrm_decode_session was originally intended\nonly for the receive path. IP6CB(skb)->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->lookuptbl[*block_number]\n\t\t\t\tif (wl)\n  wl_entry_destroy\n    ubi->lookuptbl[e->pnum] = NULL\n    kmem_cache_free(ubi_wl_entry_slab, e)\n\t\t                   erase_count = wl->ec  // UAF!\n\nWear-leveling entry updating/accessing in ubi->lookuptbl should be\nprotected by ubi->wl_lock, fix it by adding ubi->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->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->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->recovery_cp is set\n     to MaxSector.\n  2) recovery is woken and it is skipped. conf->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's replacement.\n  5) recovery is woken, A have replacement, but conf->have_replacemnt is\n     0. r10bio->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 ("md/raid10: Allow skipping recovery when clean arrays are assembled")(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'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    [<00000000b391296d>] drm_mode_duplicate+0x45/0x220 [drm]\n    [<00000000e45bb5b3>] drm_client_target_cloned.constprop.0+0x27b/0x480 [drm]\n    [<00000000ed2d3a37>] drm_client_modeset_probe+0x6bd/0xf50 [drm]\n    [<0000000010e5cc9d>] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]\n    [<00000000909f82ca>] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]\n    [<00000000063a69aa>] drm_client_register+0x169/0x240 [drm]\n    [<00000000a8c61525>] ast_pci_probe+0x142/0x190 [ast]\n    [<00000000987f19bb>] local_pci_probe+0xdc/0x180\n    [<000000004fca231b>] work_for_cpu_fn+0x4e/0xa0\n    [<0000000000b85301>] process_one_work+0x8b7/0x1540\n    [<000000003375b17c>] worker_thread+0x70a/0xed0\n    [<00000000b0d43cd9>] kthread+0x29f/0x340\n    [<000000008d770833>] 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 'conf->bio_split'\n\nIn the error path of raid10_run(), 'conf' need be freed, however,\n'conf->bio_split' is missed and memory will be leaked.\n\nSince there are 3 places to free 'conf', 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): [<ffffda301e85b7bc>] finish_task_switch+0xb4/0x2b0\n  hardirqs last disabled at (36): [<ffffda301e812fec>] cpuhp_thread_fun+0x21c/0x248\n  softirqs last  enabled at (0): [<ffffda301e80b184>] copy_process+0x63c/0x1ac0\n  softirqs last disabled at (0): [<0000000000000000>] 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 'per CPU hotplug thread'.\nPreemption is enabled in those threads, but their cpumask is limited\nto 1 CPU.\nMove 'WARN_ON_ONCE(preemptible())' statements so that SDEI cpuhp cb\ndon'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'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)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2601.4.0.0359.oe2003sp4"}]}],"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"]}}],"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"}],"database_specific":{"severity":"High"}}