{"schema_version":"1.7.2","id":"OESA-2025-1370","modified":"2025-04-03T12:54:28Z","published":"2025-04-03T12:54:28Z","upstream":["CVE-2021-47633","CVE-2022-49095","CVE-2022-49235","CVE-2022-49247","CVE-2022-49275","CVE-2022-49337","CVE-2022-49354","CVE-2022-49367","CVE-2022-49395","CVE-2022-49397","CVE-2022-49407","CVE-2022-49416","CVE-2022-49425","CVE-2022-49457","CVE-2022-49478","CVE-2022-49482","CVE-2022-49503","CVE-2022-49517","CVE-2022-49619","CVE-2022-49724","CVE-2023-53005","CVE-2023-53007","CVE-2025-21722","CVE-2025-21785"],"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\nath5k: fix OOB in ath5k_eeprom_read_pcal_info_5111\n\nThe bug was found during fuzzing. Stacktrace locates it in\nath5k_eeprom_convert_pcal_info_5111.\nWhen none of the curve is selected in the loop, idx can go\nup to AR5K_EEPROM_N_PD_CURVES. The line makes pd out of bound.\npd = \u0026amp;chinfo[pier].pd_curves[idx];\n\nThere are many OOB writes using pd later in the code. So I\nadded a sanity check for idx. Checks for other loops involving\nAR5K_EEPROM_N_PD_CURVES are not needed as the loop index is not\nused outside the loops.\n\nThe patch is NOT tested with real device.\n\nThe following is the fuzzing report\n\nBUG: KASAN: slab-out-of-bounds in ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]\nWrite of size 1 at addr ffff8880174a4d60 by task modprobe/214\n\nCPU: 0 PID: 214 Comm: modprobe Not tainted 5.6.0 #1\nCall Trace:\n dump_stack+0x76/0xa0\n print_address_description.constprop.0+0x16/0x200\n ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]\n ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]\n __kasan_report.cold+0x37/0x7c\n ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]\n kasan_report+0xe/0x20\n ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]\n ? apic_timer_interrupt+0xa/0x20\n ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k]\n ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k]\n ath5k_eeprom_init+0x2513/0x6290 [ath5k]\n ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k]\n ? usleep_range+0xb8/0x100\n ? apic_timer_interrupt+0xa/0x20\n ? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k]\n ath5k_hw_init+0xb60/0x1970 [ath5k]\n ath5k_init_ah+0x6fe/0x2530 [ath5k]\n ? kasprintf+0xa6/0xe0\n ? ath5k_stop+0x140/0x140 [ath5k]\n ? _dev_notice+0xf6/0xf6\n ? apic_timer_interrupt+0xa/0x20\n ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k]\n ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k]\n ? mutex_lock+0x89/0xd0\n ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k]\n local_pci_probe+0xd3/0x160\n pci_device_probe+0x23f/0x3e0\n ? pci_device_remove+0x280/0x280\n ? pci_device_remove+0x280/0x280\n really_probe+0x209/0x5d0(CVE-2021-47633)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: zorro7xx: Fix a resource leak in zorro7xx_remove_one()\n\nThe error handling path of the probe releases a resource that is not freed\nin the remove function. In some cases, a ioremap() must be undone.\n\nAdd the missing iounmap() call in the remove function.(CVE-2022-49095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nath9k_htc: fix uninit value bugs\n\nSyzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing\nfield initialization.\n\nIn htc_connect_service() svc_meta_len and pad are not initialized. Based\non code it looks like in current skb there is no service data, so simply\ninitialize svc_meta_len to 0.\n\nhtc_issue_send() does not initialize htc_frame_hdr::control array. Based\non firmware code, it will initialize it by itself, so simply zero whole\narray to make KMSAN happy\n\nFail logs:\n\nBUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430\n usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430\n hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline]\n hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479\n htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline]\n htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275\n...\n\nUninit was created at:\n slab_post_alloc_hook mm/slab.h:524 [inline]\n slab_alloc_node mm/slub.c:3251 [inline]\n __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974\n kmalloc_reserve net/core/skbuff.c:354 [inline]\n __alloc_skb+0x545/0xf90 net/core/skbuff.c:426\n alloc_skb include/linux/skbuff.h:1126 [inline]\n htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258\n...\n\nBytes 4-7 of 18 are uninitialized\nMemory access of size 18 starts at ffff888027377e00\n\nBUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430\n usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430\n hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline]\n hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479\n htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline]\n htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275\n...\n\nUninit was created at:\n slab_post_alloc_hook mm/slab.h:524 [inline]\n slab_alloc_node mm/slub.c:3251 [inline]\n __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974\n kmalloc_reserve net/core/skbuff.c:354 [inline]\n __alloc_skb+0x545/0xf90 net/core/skbuff.c:426\n alloc_skb include/linux/skbuff.h:1126 [inline]\n htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258\n...\n\nBytes 16-17 of 18 are uninitialized\nMemory access of size 18 starts at ffff888027377e00(CVE-2022-49235)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: stk1160: If start stream fails, return buffers with VB2_BUF_STATE_QUEUED\n\nIf the callback \u0026apos;start_streaming\u0026apos; fails, then all\nqueued buffers in the driver should be returned with\nstate \u0026apos;VB2_BUF_STATE_QUEUED\u0026apos;. Currently, they are\nreturned with \u0026apos;VB2_BUF_STATE_ERROR\u0026apos; which is wrong.\nFix this. This also fixes the warning:\n\n[   65.583633] WARNING: CPU: 5 PID: 593 at drivers/media/common/videobuf2/videobuf2-core.c:1612 vb2_start_streaming+0xd4/0x160 [videobuf2_common]\n[   65.585027] Modules linked in: snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi snd_soc_hdmi_codec dw_hdmi_i2s_audio saa7115 stk1160 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc crct10dif_ce panfrost snd_soc_simple_card snd_soc_audio_graph_card snd_soc_spdif_tx snd_soc_simple_card_utils gpu_sched phy_rockchip_pcie snd_soc_rockchip_i2s rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi cec drm_kms_helper drm rtc_rk808 rockchip_saradc industrialio_triggered_buffer kfifo_buf rockchip_thermal pcie_rockchip_host ip_tables x_tables ipv6\n[   65.589383] CPU: 5 PID: 593 Comm: v4l2src0:src Tainted: G        W         5.16.0-rc4-62408-g32447129cb30-dirty #14\n[   65.590293] Hardware name: Radxa ROCK Pi 4B (DT)\n[   65.590696] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   65.591304] pc : vb2_start_streaming+0xd4/0x160 [videobuf2_common]\n[   65.591850] lr : vb2_start_streaming+0x6c/0x160 [videobuf2_common]\n[   65.592395] sp : ffff800012bc3ad0\n[   65.592685] x29: ffff800012bc3ad0 x28: 0000000000000000 x27: ffff800012bc3cd8\n[   65.593312] x26: 0000000000000000 x25: ffff00000d8a7800 x24: 0000000040045612\n[   65.593938] x23: ffff800011323000 x22: ffff800012bc3cd8 x21: ffff00000908a8b0\n[   65.594562] x20: ffff00000908a8c8 x19: 00000000fffffff4 x18: ffffffffffffffff\n[   65.595188] x17: 000000040044ffff x16: 00400034b5503510 x15: ffff800011323f78\n[   65.595813] x14: ffff000013163886 x13: ffff000013163885 x12: 00000000000002ce\n[   65.596439] x11: 0000000000000028 x10: 0000000000000001 x9 : 0000000000000228\n[   65.597064] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff726c5e78\n[   65.597690] x5 : ffff800012bc3990 x4 : 0000000000000000 x3 : ffff000009a34880\n[   65.598315] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000007cd99f0\n[   65.598940] Call trace:\n[   65.599155]  vb2_start_streaming+0xd4/0x160 [videobuf2_common]\n[   65.599672]  vb2_core_streamon+0x17c/0x1a8 [videobuf2_common]\n[   65.600179]  vb2_streamon+0x54/0x88 [videobuf2_v4l2]\n[   65.600619]  vb2_ioctl_streamon+0x54/0x60 [videobuf2_v4l2]\n[   65.601103]  v4l_streamon+0x3c/0x50 [videodev]\n[   65.601521]  __video_do_ioctl+0x1a4/0x428 [videodev]\n[   65.601977]  video_usercopy+0x320/0x828 [videodev]\n[   65.602419]  video_ioctl2+0x3c/0x58 [videodev]\n[   65.602830]  v4l2_ioctl+0x60/0x90 [videodev]\n[   65.603227]  __arm64_sys_ioctl+0xa8/0xe0\n[   65.603576]  invoke_syscall+0x54/0x118\n[   65.603911]  el0_svc_common.constprop.3+0x84/0x100\n[   65.604332]  do_el0_svc+0x34/0xa0\n[   65.604625]  el0_svc+0x1c/0x50\n[   65.604897]  el0t_64_sync_handler+0x88/0xb0\n[   65.605264]  el0t_64_sync+0x16c/0x170\n[   65.605587] ---[ end trace 578e0ba07742170d ]---(CVE-2022-49247)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: m_can: m_can_tx_handler(): fix use after free of skb\n\ncan_put_echo_skb() will clone skb then free the skb. Move the\ncan_put_echo_skb() for the m_can version 3.0.x directly before the\nstart of the xmit in hardware, similar to the 3.1.x branch.(CVE-2022-49275)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: dlmfs: fix error handling of user_dlm_destroy_lock\n\nWhen user_dlm_destroy_lock failed, it didn\u0026apos;t clean up the flags it set\nbefore exit.  For USER_LOCK_IN_TEARDOWN, if this function fails because of\nlock is still in used, next time when unlink invokes this function, it\nwill return succeed, and then unlink will remove inode and dentry if lock\nis not in used(file closed), but the dlm lock is still linked in dlm lock\nresource, then when bast come in, it will trigger a panic due to\nuser-after-free.  See the following panic call trace.  To fix this,\nUSER_LOCK_IN_TEARDOWN should be reverted if fail.  And also error should\nbe returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink\nfail.\n\nFor the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN,\nUSER_LOCK_BUSY is also required to be cleared.  Even though spin lock is\nreleased in between, but USER_LOCK_IN_TEARDOWN is still set, for\nUSER_LOCK_BUSY, if before every place that waits on this flag,\nUSER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow\nwaits on the busy flag set by user_dlm_destroy_lock(), then we can\nsimplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails.  Fix\nuser_dlm_cluster_lock() which is the only function not following this.\n\n[  941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink\n004fb0000060000b5a90b8c847b72e1, error -16 from destroy\n[  989.757536] ------------[ cut here ]------------\n[  989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173!\n[  989.757876] invalid opcode: 0000 [#1] SMP\n[  989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O)\nksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc\nxen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5\nauth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs\nocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc\nfcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc\nrds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad\nrdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE)\nmlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad\nib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support\npcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si\nipmi_msghandler\n[  989.760686]  ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp\npps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel\nbe2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio\nlibiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi\ndm_mirror dm_region_hash dm_log dm_mod [last unloaded:\nksplice_2zhuk2jr_ib_ipoib_old]\n[  989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P           OE\n4.1.12-124.57.1.el6uek.x86_64 #2\n[  989.762290] Hardware name: Oracle Corporation ORACLE SERVER\nX5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021\n[  989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti:\nffff88017f7c8000\n[  989.762848] RIP: e030:[\u0026lt;ffffffffc07d4316\u0026gt;]  [\u0026lt;ffffffffc07d4316\u0026gt;]\n__user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs]\n[  989.763185] RSP: e02b:ffff88017f7cbcb8  EFLAGS: 00010246\n[  989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX:\n0000000000000003\n[  989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI:\nffff880174d48170\n[  989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09:\n0000000000000000\n[  989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12:\nffff880174d48008\n[  989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15:\nffff88021db7a000\n[  989.764422] FS:  0000000000000000(0000) GS:ffff880247480000(0000)\nknlGS:ffff880247480000\n[  989.764685] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4:\n0000000000042660\n[  989.765081] Stack:\n[  989.765167]  00000000000\n---truncated---(CVE-2022-49337)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe\n\nof_find_device_by_node() takes reference, we should use put_device()\nto release it when not need anymore.\nAdd missing put_device() to avoid refcount leak.(CVE-2022-49354)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register\n\nof_get_child_by_name() returns a node pointer with refcount\nincremented, we should use of_node_put() on it when done.\n\nmv88e6xxx_mdio_register() pass the device node to of_mdiobus_register().\nWe don\u0026apos;t need the device node after it.\n\nAdd missing of_node_put() to avoid refcount leak.(CVE-2022-49367)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: Fix out-of-bounds read in LDT setup\n\nsyscall_stub_data() expects the data_count parameter to be the number of\nlongs, not bytes.\n\n ==================================================================\n BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0\n Read of size 128 at addr 000000006411f6f0 by task swapper/1\n\n CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18\n Call Trace:\n  show_stack.cold+0x166/0x2a7\n  __dump_stack+0x3a/0x43\n  dump_stack_lvl+0x1f/0x27\n  print_report.cold+0xdb/0xf81\n  kasan_report+0x119/0x1f0\n  kasan_check_range+0x3a3/0x440\n  memcpy+0x52/0x140\n  syscall_stub_data+0x70/0xe0\n  write_ldt_entry+0xac/0x190\n  init_new_ldt+0x515/0x960\n  init_new_context+0x2c4/0x4d0\n  mm_init.constprop.0+0x5ed/0x760\n  mm_alloc+0x118/0x170\n  0x60033f48\n  do_one_initcall+0x1d7/0x860\n  0x60003e7b\n  kernel_init+0x6e/0x3d4\n  new_thread_handler+0x1e7/0x2c0\n\n The buggy address belongs to stack of task swapper/1\n  and is located at offset 64 in frame:\n  init_new_ldt+0x0/0x960\n\n This frame has 2 objects:\n  [32, 40) \u0026apos;addr\u0026apos;\n  [64, 80) \u0026apos;desc\u0026apos;\n ==================================================================(CVE-2022-49395)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nphy: qcom-qmp: fix struct clk leak on probe errors\n\nMake sure to release the pipe clock reference in case of a late probe\nerror (e.g. probe deferral).(CVE-2022-49397)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndlm: fix plock invalid read\n\nThis patch fixes an invalid read showed by KASAN. A unlock will allocate a\n\u0026quot;struct plock_op\u0026quot; and a followed send_op() will append it to a global\nsend_list data structure. In some cases a followed dev_read() moves it\nto recv_list and dev_write() will cast it to \u0026quot;struct plock_xop\u0026quot; and access\nfields which are only available in those structures. At this point an\ninvalid read happens by accessing those fields.\n\nTo fix this issue the \u0026quot;callback\u0026quot; field is moved to \u0026quot;struct plock_op\u0026quot; to\nindicate that a cast to \u0026quot;plock_xop\u0026quot; is allowed and does the additional\n\u0026quot;plock_xop\u0026quot; handling if set.\n\nExample of the KASAN output which showed the invalid read:\n\n[ 2064.296453] ==================================================================\n[ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm]\n[ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484\n[ 2064.308168]\n[ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9\n[ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011\n[ 2064.311618] Call Trace:\n[ 2064.312218]  dump_stack_lvl+0x56/0x7b\n[ 2064.313150]  print_address_description.constprop.8+0x21/0x150\n[ 2064.314578]  ? dev_write+0x52b/0x5a0 [dlm]\n[ 2064.315610]  ? dev_write+0x52b/0x5a0 [dlm]\n[ 2064.316595]  kasan_report.cold.14+0x7f/0x11b\n[ 2064.317674]  ? dev_write+0x52b/0x5a0 [dlm]\n[ 2064.318687]  dev_write+0x52b/0x5a0 [dlm]\n[ 2064.319629]  ? dev_read+0x4a0/0x4a0 [dlm]\n[ 2064.320713]  ? bpf_lsm_kernfs_init_security+0x10/0x10\n[ 2064.321926]  vfs_write+0x17e/0x930\n[ 2064.322769]  ? __fget_light+0x1aa/0x220\n[ 2064.323753]  ksys_write+0xf1/0x1c0\n[ 2064.324548]  ? __ia32_sys_read+0xb0/0xb0\n[ 2064.325464]  do_syscall_64+0x3a/0x80\n[ 2064.326387]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n[ 2064.327606] RIP: 0033:0x7f807e4ba96f\n[ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48\n[ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001\n[ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f\n[ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010\n[ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001\n[ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80\n[ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001\n[ 2064.342857]\n[ 2064.343226] Allocated by task 12438:\n[ 2064.344057]  kasan_save_stack+0x1c/0x40\n[ 2064.345079]  __kasan_kmalloc+0x84/0xa0\n[ 2064.345933]  kmem_cache_alloc_trace+0x13b/0x220\n[ 2064.346953]  dlm_posix_unlock+0xec/0x720 [dlm]\n[ 2064.348811]  do_lock_file_wait.part.32+0xca/0x1d0\n[ 2064.351070]  fcntl_setlk+0x281/0xbc0\n[ 2064.352879]  do_fcntl+0x5e4/0xfe0\n[ 2064.354657]  __x64_sys_fcntl+0x11f/0x170\n[ 2064.356550]  do_syscall_64+0x3a/0x80\n[ 2064.358259]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n[ 2064.360745]\n[ 2064.361511] Last potentially related work creation:\n[ 2064.363957]  kasan_save_stack+0x1c/0x40\n[ 2064.365811]  __kasan_record_aux_stack+0xaf/0xc0\n[ 2064.368100]  call_rcu+0x11b/0xf70\n[ 2064.369785]  dlm_process_incoming_buffer+0x47d/0xfd0 [dlm]\n[ 2064.372404]  receive_from_sock+0x290/0x770 [dlm]\n[ 2064.374607]  process_recv_sockets+0x32/0x40 [dlm]\n[ 2064.377290]  process_one_work+0x9a8/0x16e0\n[ 2064.379357]  worker_thread+0x87/0xbf0\n[ 2064.381188]  kthread+0x3ac/0x490\n[ 2064.383460]  ret_from_fork+0x22/0x30\n[ 2064.385588]\n[ 2064.386518] Second to last potentially related work creation:\n[ 2064.389219]  kasan_save_stack+0x1c/0x40\n[ 2064.391043]  __kasan_record_aux_stack+0xaf/0xc0\n[ 2064.393303]  call_rcu+0x11b/0xf70\n[ 2064.394885]  dlm_process_incoming_buffer+0x47d/0xfd0 [dlm]\n[ 2064.397694]  receive_from_sock+0x290/0x770 \n---truncated---(CVE-2022-49407)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: fix use-after-free in chanctx code\n\nIn ieee80211_vif_use_reserved_context(), when we have an\nold context and the new context\u0026apos;s replace_state is set to\nIEEE80211_CHANCTX_REPLACE_NONE, we free the old context\nin ieee80211_vif_use_reserved_reassign(). Therefore, we\ncannot check the old_ctx anymore, so we should set it to\nNULL after this point.\n\nHowever, since the new_ctx replace state is clearly not\nIEEE80211_CHANCTX_REPLACES_OTHER, we\u0026apos;re not going to do\nanything else in this function and can just return to\navoid accessing the freed old_ctx.(CVE-2022-49416)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix dereference of stale list iterator after loop body\n\nThe list iterator variable will be a bogus pointer if no break was hit.\nDereferencing it (cur-\u0026gt;page in this case) could load an out-of-bounds/undefined\nvalue making it unsafe to use that in the comparision to determine if the\nspecific element was found.\n\nSince \u0026apos;cur-\u0026gt;page\u0026apos; *can* be out-ouf-bounds it cannot be guaranteed that\nby chance (or intention of an attacker) it matches the value of \u0026apos;page\u0026apos;\neven though the correct element was not found.\n\nThis is fixed by using a separate list iterator variable for the loop\nand only setting the original variable if a suitable element was found.\nThen determing if the element was found is simply checking if the\nvariable is set.(CVE-2022-49425)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: versatile: Add missing of_node_put in dcscb_init\n\nThe device_node pointer is returned by of_find_compatible_node\nwith refcount incremented. We should use of_node_put() to avoid\nthe refcount leak.(CVE-2022-49457)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init\n\nSyzbot reported that -1 is used as array index. The problem was in\nmissing validation check.\n\nhdw-\u0026gt;unit_number is initialized with -1 and then if init table walk fails\nthis value remains unchanged. Since code blindly uses this member for\narray indexing adding sanity check is the easiest fix for that.\n\nhdw-\u0026gt;workpoll initialization moved upper to prevent warning in\n__flush_work.(CVE-2022-49478)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: mxs-saif: Fix refcount leak in mxs_saif_probe\n\nof_parse_phandle() returns a node pointer with refcount\nincremented, we should use of_node_put() on it when done.(CVE-2022-49482)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nath9k_htc: fix potential out of bounds access with invalid rxstatus-\u0026gt;rs_keyix\n\nThe \u0026quot;rxstatus-\u0026gt;rs_keyix\u0026quot; eventually gets passed to test_bit() so we need to\nensure that it is within the bitmap.\n\ndrivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept()\nerror: passing untrusted data \u0026apos;rx_stats-\u0026gt;rs_keyix\u0026apos; to \u0026apos;test_bit()\u0026apos;(CVE-2022-49503)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: mediatek: Fix missing of_node_put in mt2701_wm8960_machine_probe\n\nThis node pointer is returned by of_parse_phandle() with\nrefcount incremented in this function.\nCalling of_node_put() to avoid the refcount leak.(CVE-2022-49517)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sfp: fix memory leak in sfp_probe()\n\nsfp_probe() allocates a memory chunk from sfp with sfp_alloc(). When\ndevm_add_action() fails, sfp is not freed, which leads to a memory leak.\n\nWe should use devm_add_action_or_reset() instead of devm_add_action().(CVE-2022-49619)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntty: goldfish: Fix free_irq() on remove\n\nPass the correct dev_id to free_irq() to fix this splat when the driver\nis unbound:\n\n WARNING: CPU: 0 PID: 30 at kernel/irq/manage.c:1895 free_irq\n Trying to free already-free IRQ 65\n Call Trace:\n  warn_slowpath_fmt\n  free_irq\n  goldfish_tty_remove\n  platform_remove\n  device_remove\n  device_release_driver_internal\n  device_driver_detach\n  unbind_store\n  drv_attr_store\n  ...(CVE-2022-49724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntrace_events_hist: add check for return value of \u0026apos;create_hist_field\u0026apos;\n\nFunction \u0026apos;create_hist_field\u0026apos; is called recursively at\ntrace_events_hist.c:1954 and can return NULL-value that\u0026apos;s why we have\nto check it to avoid null pointer dereference.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-53005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Make sure trace_printk() can output as soon as it can be used\n\nCurrently trace_printk() can be used as soon as early_trace_init() is\ncalled from start_kernel(). But if a crash happens, and\n\u0026quot;ftrace_dump_on_oops\u0026quot; is set on the kernel command line, all you get will\nbe:\n\n  [    0.456075]   \u0026lt;idle\u0026gt;-0         0dN.2. 347519us : Unknown type 6\n  [    0.456075]   \u0026lt;idle\u0026gt;-0         0dN.2. 353141us : Unknown type 6\n  [    0.456075]   \u0026lt;idle\u0026gt;-0         0dN.2. 358684us : Unknown type 6\n\nThis is because the trace_printk() event (type 6) hasn\u0026apos;t been registered\nyet. That gets done via an early_initcall(), which may be early, but not\nearly enough.\n\nInstead of registering the trace_printk() event (and other ftrace events,\nwhich are not trace events) via an early_initcall(), have them registered at\nthe same time that trace_printk() can be used. This way, if there is a\ncrash before early_initcall(), then the trace_printk()s will actually be\nuseful.(CVE-2023-53007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: do not force clear folio if buffer is referenced\n\nPatch series \u0026quot;nilfs2: protect busy buffer heads from being force-cleared\u0026quot;.\n\nThis series fixes the buffer head state inconsistency issues reported by\nsyzbot that occurs when the filesystem is corrupted and falls back to\nread-only, and the associated buffer head use-after-free issue.\n\n\nThis patch (of 2):\n\nSyzbot has reported that after nilfs2 detects filesystem corruption and\nfalls back to read-only, inconsistencies in the buffer state may occur.\n\nOne of the inconsistencies is that when nilfs2 calls mark_buffer_dirty()\nto set a data or metadata buffer as dirty, but it detects that the buffer\nis not in the uptodate state:\n\n WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520\n  fs/buffer.c:1177\n ...\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598\n  nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73\n  nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344\n  nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218\n  vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n  do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n  __do_sys_mkdirat fs/namei.c:4295 [inline]\n  __se_sys_mkdirat fs/namei.c:4293 [inline]\n  __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThe other is when nilfs_btree_propagate(), which propagates the dirty\nstate to the ancestor nodes of a b-tree that point to a dirty buffer,\ndetects that the origin buffer is not dirty, even though it should be:\n\n WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089\n  nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089\n ...\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345\n  nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587\n  nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006\n  nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045\n  nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline]\n  nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline]\n  nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115\n  nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479\n  nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline]\n  nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701\n  kthread+0x2f0/0x390 kernel/kthread.c:389\n  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n  \u0026lt;/TASK\u0026gt;\n\nBoth of these issues are caused by the callbacks that handle the\npage/folio write requests, forcibly clear various states, including the\nworking state of the buffers they hold, at unexpected times when they\ndetect read-only fallback.\n\nFix these issues by checking if the buffer is referenced before clearing\nthe page/folio state, and skipping the clear if it is.(CVE-2025-21722)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array\n\nThe loop that detects/populates cache information already has a bounds\ncheck on the array size but does not account for cache levels with\nseparate data/instructions cache. Fix this by incrementing the index\nfor any populated leaf (instead of any populated level).(CVE-2025-21785)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2504.1.0.0322.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","kernel-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","perf-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2504.1.0.0322.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2504.1.0.0322.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","kernel-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","perf-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2504.1.0.0322.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1370"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47633"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49095"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49235"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49247"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49275"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49337"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49354"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49367"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49395"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49397"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49407"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49416"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49425"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49457"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49478"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49482"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49503"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49517"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49619"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49724"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53005"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53007"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21722"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21785"}],"database_specific":{"severity":"High"}}