kernel-5.14.0-570.32.1.el9_6
エラータID: AXSA:2025-10781:59
リリース日:
2025/08/27 Wednesday - 09:13
題名:
kernel-5.14.0-570.32.1.el9_6
影響のあるチャネル:
MIRACLE LINUX 9 for x86_64
Severity:
High
Description:
以下項目について対処しました。
[Security Fix]
- kernel の vmci ドライバには、メモリ領域の解放処理が欠落して
いるため、ローカルの攻撃者により、情報の漏洩、およびサービス拒否
攻撃 (メモリ枯渇) を可能とする脆弱性が存在します。(CVE-2022-49788)
- kernel の padata の実装には、メモリ領域の解放後利用の問題が
あるため、ローカルの攻撃者により、情報の漏洩、データ破壊、および
サービス拒否攻撃を可能とする脆弱性が存在します。(CVE-2025-21727)
- kernel の HID ドライバには、メモリ領域の解放後利用の問題が
あるため、ローカルの攻撃者により、情報の漏洩、データ破壊、および
サービス拒否攻撃を可能とする脆弱性が存在します。(CVE-2025-21928)
- kernel の HID ドライバには、メモリ領域の解放後利用の問題が
あるため、ローカルの攻撃者により、情報の漏洩、データ破壊、および
サービス拒否攻撃を可能とする脆弱性が存在します。(CVE-2025-21929)
- kernel の CIFS の実装には、整数オーバーフローの問題があるため、
ローカルの攻撃者により、情報の漏洩、およびサービス拒否攻撃を可能
とする脆弱性が存在します。(CVE-2025-21962)
- kernel の Realtek USB メモリスティックドライバには、メモリ領域
の解放後利用の問題があるため、ローカルの攻撃者により、情報の漏洩、
データ破壊、およびサービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2025-22020)
- kernel の HFSC スケジューラには、メモリ領域の解放後利用の問題
があるため、ローカルの攻撃者により、情報の漏洩、データ破壊、および
サービス拒否攻撃を可能とする脆弱性が存在します。(CVE-2025-37890)
- kernel の TIPC サブシステムには、メモリ領域の解放後利用の問題が
あるため、ローカルの攻撃者により、情報の漏洩、データ破壊、および
サービス拒否攻撃を可能とする脆弱性が存在します。(CVE-2025-38052)
- kernel の taprio スケジューラには、メモリ領域の解放後利用の
問題があるため、ローカルの攻撃者により、情報の漏洩、データ破壊、
およびサービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2025-38087)
解決策:
パッケージをアップデートしてください。
CVE:
CVE-2022-49788
In the Linux kernel, the following vulnerability has been resolved: misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram() `struct vmci_event_qp` allocated by qp_notify_peer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN: BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121 instrument_copy_to_user ./include/linux/instrumented.h:121 _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 copy_to_user ./include/linux/uaccess.h:169 vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431 vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925 vfs_ioctl fs/ioctl.c:51 ... Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271 vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339 qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940 vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488 vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927 ... Local variable ev created at: qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100 Use memset() to prevent the infoleaks. Also speculatively fix qp_notify_peer_local(), which may suffer from the same problem.
In the Linux kernel, the following vulnerability has been resolved: misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram() `struct vmci_event_qp` allocated by qp_notify_peer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN: BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121 instrument_copy_to_user ./include/linux/instrumented.h:121 _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 copy_to_user ./include/linux/uaccess.h:169 vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431 vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925 vfs_ioctl fs/ioctl.c:51 ... Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271 vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339 qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940 vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488 vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927 ... Local variable ev created at: qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100 Use memset() to prevent the infoleaks. Also speculatively fix qp_notify_peer_local(), which may suffer from the same problem.
CVE-2025-21727
In the Linux kernel, the following vulnerability has been resolved: padata: fix UAF in padata_reorder A bug was found when run ltp test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01). This can be explained as bellow: pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF } In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF. As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish. [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/
In the Linux kernel, the following vulnerability has been resolved: padata: fix UAF in padata_reorder A bug was found when run ltp test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace:
CVE-2025-21928
In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove() The system can experience a random crash a few minutes after the driver is removed. This issue occurs due to improper handling of memory freeing in the ishtp_hid_remove() function. The function currently frees the `driver_data` directly within the loop that destroys the HID devices, which can lead to accessing freed memory. Specifically, `hid_destroy_device()` uses `driver_data` when it calls `hid_ishtp_set_feature()` to power off the sensor, so freeing `driver_data` beforehand can result in accessing invalid memory. This patch resolves the issue by storing the `driver_data` in a temporary variable before calling `hid_destroy_device()`, and then freeing the `driver_data` after the device is destroyed.
In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove() The system can experience a random crash a few minutes after the driver is removed. This issue occurs due to improper handling of memory freeing in the ishtp_hid_remove() function. The function currently frees the `driver_data` directly within the loop that destroys the HID devices, which can lead to accessing freed memory. Specifically, `hid_destroy_device()` uses `driver_data` when it calls `hid_ishtp_set_feature()` to power off the sensor, so freeing `driver_data` beforehand can result in accessing invalid memory. This patch resolves the issue by storing the `driver_data` in a temporary variable before calling `hid_destroy_device()`, and then freeing the `driver_data` after the device is destroyed.
CVE-2025-21929
In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix use-after-free issue in hid_ishtp_cl_remove() During the `rmmod` operation for the `intel_ishtp_hid` driver, a use-after-free issue can occur in the hid_ishtp_cl_remove() function. The function hid_ishtp_cl_deinit() is called before ishtp_hid_remove(), which can lead to accessing freed memory or resources during the removal process. Call Trace: ? ishtp_cl_send+0x168/0x220 [intel_ishtp] ? hid_output_report+0xe3/0x150 [hid] hid_ishtp_set_feature+0xb5/0x120 [intel_ishtp_hid] ishtp_hid_request+0x7b/0xb0 [intel_ishtp_hid] hid_hw_request+0x1f/0x40 [hid] sensor_hub_set_feature+0x11f/0x190 [hid_sensor_hub] _hid_sensor_power_state+0x147/0x1e0 [hid_sensor_trigger] hid_sensor_runtime_resume+0x22/0x30 [hid_sensor_trigger] sensor_hub_remove+0xa8/0xe0 [hid_sensor_hub] hid_device_remove+0x49/0xb0 [hid] hid_destroy_device+0x6f/0x90 [hid] ishtp_hid_remove+0x42/0x70 [intel_ishtp_hid] hid_ishtp_cl_remove+0x6b/0xb0 [intel_ishtp_hid] ishtp_cl_device_remove+0x4a/0x60 [intel_ishtp] ... Additionally, ishtp_hid_remove() is a HID level power off, which should occur before the ISHTP level disconnect. This patch resolves the issue by reordering the calls in hid_ishtp_cl_remove(). The function ishtp_hid_remove() is now called before hid_ishtp_cl_deinit().
In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix use-after-free issue in hid_ishtp_cl_remove() During the `rmmod` operation for the `intel_ishtp_hid` driver, a use-after-free issue can occur in the hid_ishtp_cl_remove() function. The function hid_ishtp_cl_deinit() is called before ishtp_hid_remove(), which can lead to accessing freed memory or resources during the removal process. Call Trace: ? ishtp_cl_send+0x168/0x220 [intel_ishtp] ? hid_output_report+0xe3/0x150 [hid] hid_ishtp_set_feature+0xb5/0x120 [intel_ishtp_hid] ishtp_hid_request+0x7b/0xb0 [intel_ishtp_hid] hid_hw_request+0x1f/0x40 [hid] sensor_hub_set_feature+0x11f/0x190 [hid_sensor_hub] _hid_sensor_power_state+0x147/0x1e0 [hid_sensor_trigger] hid_sensor_runtime_resume+0x22/0x30 [hid_sensor_trigger] sensor_hub_remove+0xa8/0xe0 [hid_sensor_hub] hid_device_remove+0x49/0xb0 [hid] hid_destroy_device+0x6f/0x90 [hid] ishtp_hid_remove+0x42/0x70 [intel_ishtp_hid] hid_ishtp_cl_remove+0x6b/0xb0 [intel_ishtp_hid] ishtp_cl_device_remove+0x4a/0x60 [intel_ishtp] ... Additionally, ishtp_hid_remove() is a HID level power off, which should occur before the ISHTP level disconnect. This patch resolves the issue by reordering the calls in hid_ishtp_cl_remove(). The function ishtp_hid_remove() is now called before hid_ishtp_cl_deinit().
CVE-2025-21962
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix integer overflow while processing closetimeo mount option User-provided mount parameter closetimeo of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE.
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix integer overflow while processing closetimeo mount option User-provided mount parameter closetimeo of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2025-22020
In the Linux kernel, the following vulnerability has been resolved: memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove This fixes the following crash: ================================================================== BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241 CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNED_MODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms] Call Trace: dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x27/0x320 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] print_report+0x3e/0x70 kasan_report+0xab/0xe0 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms] ? __pfx___schedule+0x10/0x10 ? kick_pool+0x3b/0x270 process_one_work+0x357/0x660 worker_thread+0x390/0x4c0 ? __pfx_worker_thread+0x10/0x10 kthread+0x190/0x1d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 161446: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x1a7/0x470 memstick_alloc_host+0x1f/0xe0 [memstick] rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms] platform_probe+0x60/0xe0 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 bus_probe_device+0xbd/0xd0 device_add+0x4a5/0x760 platform_device_add+0x189/0x370 mfd_add_device+0x587/0x5e0 mfd_add_devices+0xb1/0x130 rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb] usb_probe_interface+0x15c/0x460 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 rebind_marked_interfaces.isra.0+0xcc/0x110 usb_reset_device+0x352/0x410 usbdev_do_ioctl+0xe5c/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 161506: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x36/0x60 __kasan_slab_free+0x34/0x50 kfree+0x1fd/0x3b0 device_release+0x56/0xf0 kobject_cleanup+0x73/0x1c0 rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms] platform_remove+0x2f/0x50 device_release_driver_internal+0x24b/0x2e0 bus_remove_device+0x124/0x1d0 device_del+0x239/0x530 platform_device_del.part.0+0x19/0xe0 platform_device_unregister+0x1c/0x40 mfd_remove_devices_fn+0x167/0x170 device_for_each_child_reverse+0xc9/0x130 mfd_remove_devices+0x6e/0xa0 rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb] usb_unbind_interface+0xf3/0x3f0 device_release_driver_internal+0x24b/0x2e0 proc_disconnect_claim+0x13d/0x220 usbdev_do_ioctl+0xb5e/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x360 __irq_exit_rcu+0x114/0x130 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20 Second to last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x ---truncated---
In the Linux kernel, the following vulnerability has been resolved: memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove This fixes the following crash: ================================================================== BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241 CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNED_MODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms] Call Trace:
CVE-2025-37890
In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc As described in Gerrard's report [1], we have a UAF case when an hfsc class has a netem child qdisc. The crux of the issue is that hfsc is assuming that checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted the class in the vttree or eltree (which is not true for the netem duplicate case). This patch checks the n_active class variable to make sure that the code won't insert the class in the vttree or eltree twice, catering for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc As described in Gerrard's report [1], we have a UAF case when an hfsc class has a netem child qdisc. The crux of the issue is that hfsc is assuming that checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted the class in the vttree or eltree (which is not true for the netem duplicate case). This patch checks the n_active class variable to make sure that the code won't insert the class in the vttree or eltree twice, catering for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
CVE-2025-38052
In the Linux kernel, the following vulnerability has been resolved: net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done Syzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue. I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1 The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work) Fix this by holding net reference count before encrypt.
In the Linux kernel, the following vulnerability has been resolved: net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done Syzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue. I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1 The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work) Fix this by holding net reference count before encrypt.
CVE-2025-38087
In the Linux kernel, the following vulnerability has been resolved: net/sched: fix use-after-free in taprio_dev_notifier Since taprio’s taprio_dev_notifier() isn’t protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free. Adding rcu_read_lock() inside taprio_dev_notifier() prevents this.
In the Linux kernel, the following vulnerability has been resolved: net/sched: fix use-after-free in taprio_dev_notifier Since taprio’s taprio_dev_notifier() isn’t protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free. Adding rcu_read_lock() inside taprio_dev_notifier() prevents this.
追加情報:
N/A
ダウンロード:
SRPMS
- kernel-5.14.0-570.32.1.el9_6.src.rpm
MD5: 89a16b4b338c90f7d9bb0bd434d55ffb
SHA-256: ccde9f921003f30b5c7dd2ac9af0d62c20c604a3a34ff062b69e48b88f8e1eb6
Size: 142.49 MB
Asianux Server 9 for x86_64
- kernel-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: e66722deb6535075eed33444a9c3f674
SHA-256: b7591554bffe7a0a223a6fa97130043737832f8528857ebd20bf1ab824327333
Size: 1.78 MB - kernel-abi-stablelists-5.14.0-570.32.1.el9_6.noarch.rpm
MD5: f2e5cb9d7ae55c0a56ae7de5d724e56a
SHA-256: d7129a5c6b65fb638a77649e54fb9adf0f5d4847e0791ea00abcd370b7e62b21
Size: 1.81 MB - kernel-core-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: aee584358eb6756a825e8efbe2273d40
SHA-256: 35eab7a9e6f0d578d5a5d37144d44dc041c0cbbf4e287fa5291809d80ac598d7
Size: 17.85 MB - kernel-cross-headers-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 8a90efb78fd3b906e5c36a6d26cc5f13
SHA-256: 5a1e0745600f824b990ba4705caff805f3f7cc6ef9cd3ef6799209ac5c8dccb8
Size: 8.65 MB - kernel-debug-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 0f640d210b8c461adf567fb73090b797
SHA-256: b9458f461d521f2b5061a8d80b4dd6763356a6eab74123af856d92fab0c6210b
Size: 1.78 MB - kernel-debug-core-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 6569374ff2aed08d289d490627d5a057
SHA-256: b4680f6d50a4a3a31cf28044f53cd5dfd261029c30221cabf4e73de59be5b31e
Size: 31.29 MB - kernel-debug-devel-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 5171c776333c5b734350135633765f9c
SHA-256: f8a988444f8639acd082bb4956b0b20697ef2ee9bf99f424ac85e1e98bd0bb10
Size: 21.78 MB - kernel-debug-devel-matched-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 3968e85ada9e334ad252e63c2af70f56
SHA-256: 02120e080aee60541fd6618da42dd403d6e7be5d3f6635a72f7cce9b480eb25c
Size: 1.78 MB - kernel-debug-modules-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: f5f067379a315f21ab94e1ec74d3fa0e
SHA-256: 149c778a41622329f15f92b31639260d3581020fe5717b3237218af6044b67a5
Size: 67.44 MB - kernel-debug-modules-core-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: a2490c22b11e5207927767150ebfd0b9
SHA-256: 2d489201db4792f3eb01e32f1dac041857485903ef95b1802b306d52f36be109
Size: 48.90 MB - kernel-debug-modules-extra-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: f318b70a2012b32c996dc9aa8c9bbd3e
SHA-256: ca1d8dac3ef6ce81bee1e876d9caff3c238af6b2c1277f6ef489897233357273
Size: 2.56 MB - kernel-debug-uki-virt-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 7b0d7953e1f313bcf66d0471e833b5e6
SHA-256: e414046a1df932e2bb8ca9998f39a68f9651ca83a56a9c07ad454bce73db2daa
Size: 84.36 MB - kernel-devel-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 2cf37ef03ca0af068f35b6a98286b888
SHA-256: 082aa78598b35dd2990a6fece87a26b1dab916cc5d0349402d6bd0ce19604bfb
Size: 21.60 MB - kernel-devel-matched-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 57fc43acee2dfb4c44b64e4b70e073f3
SHA-256: 722450cf14eb92ab416c81b3973358f2eb9943ef8fd034e267c6e7feed86ac13
Size: 1.78 MB - kernel-doc-5.14.0-570.32.1.el9_6.noarch.rpm
MD5: 456b303a41779cf671b12cea02e053c3
SHA-256: 8ef1258c109d97aa66c9a6ef52d51edeffcbcb5ba4235a8ffb089e10d8cd20dc
Size: 37.92 MB - kernel-headers-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: fb3df8d8577fb2225bf2b04a3718397a
SHA-256: c94e3d98ef83b7d7d3e0a26ac8b4e2e26baf70233382364cb7fbe375ae42ea15
Size: 3.52 MB - kernel-modules-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 12a07dfe231453fe8dd51be4032da508
SHA-256: ee1b42b1ce8a94808b1b6414b4d0bf583b821e2b769914dfb6dc8beb902b1ec8
Size: 38.95 MB - kernel-modules-core-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: f41139986501da68bfedc6b8f237f1db
SHA-256: 33f67efaa01c745a4eb7252f5b232d14018393dccc6735ae504568d9e73a6deb
Size: 30.88 MB - kernel-modules-extra-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 111d272ca5bfc0412cb18611a011650d
SHA-256: 914ae90ca61d9bc445a822fa975adc666478eef10708f0df0cb923d29bda01bc
Size: 2.21 MB - kernel-rt-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 3ca99af1cd7f82b5ab5b9f75a436d056
SHA-256: 5f1623c9f2103ba3f413c5896626f9f8a355708c840b1040fc5045e07d0e9e9f
Size: 1.78 MB - kernel-rt-core-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 3979bc1a18db31a290b44f7f80b405f2
SHA-256: e489dd87d68bbdfab00fc5cfa68c5aa1a6497a2778ed502da575794a35f1988f
Size: 17.75 MB - kernel-rt-debug-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 5e0e5eb829b7e3bc6d1b366be9980028
SHA-256: 311317fb74cc1fb470de5817656ff809a06952c8c5e2759c62a968f293e1a92f
Size: 1.78 MB - kernel-rt-debug-core-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: cec357226bca3170c1de5702eee494f1
SHA-256: 5802f4cd70b2ff386ec82fcaeb9c5f3605f747440cae2e37456d6fe1755b1418
Size: 19.15 MB - kernel-rt-debug-devel-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: dd3c3c469eb75dc94ffa8df7f5bb0285
SHA-256: 20bf7eb46225a4e254ad4691619e8d44963476f56a765384f592262c51025229
Size: 21.73 MB - kernel-rt-debug-modules-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 0e89c0f2e57f77c67dbd5088ba35a93c
SHA-256: 710972be8a2a05bda2b321032ea127f4ea4ab4b86832232072e086f53f4343cc
Size: 40.37 MB - kernel-rt-debug-modules-core-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 576bee64cbf6d4dcb4b92ee655ae435d
SHA-256: 312ab5cbb2d0ed87b731132def3312e73b45742bf7287d2c82c350f87da68040
Size: 31.30 MB - kernel-rt-debug-modules-extra-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: e95c34f555a2d4ca350b5bd4af910cf0
SHA-256: 24c511a623a0fcea9de8f20b3286f9bab09610457b474b4a5463d2e12e178f0d
Size: 2.23 MB - kernel-rt-devel-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 70015063f01d192a52bc1199c217c49f
SHA-256: f52fc7b246d95192ad62c47b36d926b9f949cff2789e42ea279e263376d5929a
Size: 21.58 MB - kernel-rt-modules-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 181f818b85e512efd32c71c257aca32e
SHA-256: ecc17a2e6b5d70a006a0b895e6207168a2e0b06219009910fdfe4f806ccb0640
Size: 38.97 MB - kernel-rt-modules-core-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: d809ac3a275e0c27997a210da2c98116
SHA-256: fce985312f6d2646358dbc456dd8902e7262c341b5220e35a2fe55ef8d1c205f
Size: 30.25 MB - kernel-rt-modules-extra-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: f51d915be63050b09fed8dd441863b40
SHA-256: 80ee282185ff794bed064189b795d30303ab1e9741905bd80f38f9925b1332a4
Size: 2.21 MB - kernel-tools-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 62a62216301a867704fb850e11bde796
SHA-256: 2a1a9f22f2b90496f536d0f5597026abab8e250ab042335626e7edb7060e715d
Size: 2.07 MB - kernel-tools-libs-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: fd9dbc70bc7cd9962808a958f98458c3
SHA-256: ae9e39d4d40f67ca16c8e0732bc7b32b83e17db9741f36972f9bea9e3d51c2a2
Size: 1.80 MB - kernel-tools-libs-devel-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: dac157355fa6e7c377e6839f1105e663
SHA-256: fe4a1fda683ce98ee9e9909ff5bbf9aae9b4acf2e0dc6e251e876c92910216ab
Size: 1.79 MB - kernel-uki-virt-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: a8ef9ad6ca8ee9108e8ae87bb8bd0d39
SHA-256: 565eec1715a8076eca48fb11304ae71a393497b40a8dbe88ade6db15ccc72760
Size: 63.00 MB - kernel-uki-virt-addons-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 215598b78a8aad0d62308093bd0f6309
SHA-256: 7cc18af5170af90281019f306522915d8840bbf64c6bfd677381f689c7405521
Size: 1.81 MB - libperf-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 1479a8e4caf7c9f08df3e372c201f410
SHA-256: ed1b857ffbb8327ada3116dfd628800449ea8f7ebeb39b11cbf3868659605abf
Size: 1.81 MB - perf-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: a008100f4f391a6c8d5da33b8032382c
SHA-256: fe73356c4f0b49a4c13314b6e5f9fa3f491cb5840486317a64d83020f0d627ae
Size: 4.01 MB - python3-perf-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: b9c173da2aef84f2c2c0ca3a4aed06f1
SHA-256: ac10827f02d53cf322a28bc9d7f74a20c8e7018072f8f5b47a97b4b47ca8dde6
Size: 3.19 MB - rtla-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: fa56c14455b898a92bcbe5832619474f
SHA-256: 598382a4a708bc432310e230a488035b4c4254807caa9897935df769b205e499
Size: 1.84 MB - rv-5.14.0-570.32.1.el9_6.x86_64.rpm
MD5: 06c4ba15a88ecb9a24de33c7b4aa9704
SHA-256: 6f2de11e5533a00478ec8f217f24f388915a7ce6294170dd88147402f26d2b68
Size: 1.80 MB
English