An update for kernel is now available for openEuler-20.03-LTS-SP4 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2025-1112 Final 1.0 1.0 2025-02-14 Initial 2025-02-14 2025-02-14 openEuler SA Tool V1.0 2025-02-14 kernel security update An update for kernel is now available for openEuler-20.03-LTS-SP4 The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: Add cancel_work_sync before module remove If we remove the module which will call mpc52xx_spi_remove it will free 'ms' through spi_unregister_controller. while the work ms->work will be used. The sequence of operations that may lead to a UAF bug. Fix it by ensuring that the work is canceled before proceeding with the cleanup in mpc52xx_spi_remove.(CVE-2024-50051) In the Linux kernel, the following vulnerability has been resolved: scsi: bfa: Fix use-after-free in bfad_im_module_exit() BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20 Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303 Call Trace: <TASK> dump_stack_lvl+0x95/0xe0 print_report+0xcb/0x620 kasan_report+0xbd/0xf0 __lock_acquire+0x2aca/0x3a20 lock_acquire+0x19b/0x520 _raw_spin_lock+0x2b/0x40 attribute_container_unregister+0x30/0x160 fc_release_transport+0x19/0x90 [scsi_transport_fc] bfad_im_module_exit+0x23/0x60 [bfa] bfad_init+0xdb/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Allocated by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc] bfad_im_module_init+0x17/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x38/0x50 kfree+0x212/0x480 bfad_im_module_init+0x7e/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Above issue happens as follows: bfad_init error = bfad_im_module_init() fc_release_transport(bfad_im_scsi_transport_template); if (error) goto ext; ext: bfad_im_module_exit(); fc_release_transport(bfad_im_scsi_transport_template); --> Trigger double release Don't call bfad_im_module_exit() if bfad_im_module_init() failed.(CVE-2024-53227) In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc() bt_sock_alloc() attaches allocated sk object to the provided sock object. If rfcomm_dlc_alloc() fails, we release the sk object, but leave the dangling pointer in the sock object, which may cause use-after-free. Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().(CVE-2024-56604) In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create() bt_sock_alloc() allocates the sk object and attaches it to the provided sock object. On error l2cap_sock_alloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code.(CVE-2024-56605) In the Linux kernel, the following vulnerability has been resolved: drm: adv7511: Fix use-after-free in adv7533_attach_dsi() The host_node pointer was assigned and freed in adv7533_parse_dt(), and later, adv7533_attach_dsi() uses the same. Fix this use-after-free issue by dropping of_node_put() in adv7533_parse_dt() and calling of_node_put() in error path of probe() and also in the remove().(CVE-2024-57887) In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: oss: Fix races at processing SysEx messages OSS sequencer handles the SysEx messages split in 6 bytes packets, and ALSA sequencer OSS layer tries to combine those. It stores the data in the internal buffer and this access is racy as of now, which may lead to the out-of-bounds access. As a temporary band-aid fix, introduce a mutex for serializing the process of the SysEx message packets.(CVE-2024-57893) An update for kernel is now available for openEuler-20.03-LTS-SP4. openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. High kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1112 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-50051 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-53227 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-56604 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-56605 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-57887 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-57893 https://nvd.nist.gov/vuln/detail/CVE-2024-50051 https://nvd.nist.gov/vuln/detail/CVE-2024-53227 https://nvd.nist.gov/vuln/detail/CVE-2024-56604 https://nvd.nist.gov/vuln/detail/CVE-2024-56605 https://nvd.nist.gov/vuln/detail/CVE-2024-57887 https://nvd.nist.gov/vuln/detail/CVE-2024-57893 openEuler-20.03-LTS-SP4 bpftool-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm bpftool-debuginfo-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm kernel-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm kernel-debuginfo-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm kernel-debugsource-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm kernel-devel-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm kernel-source-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm kernel-tools-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm kernel-tools-debuginfo-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm kernel-tools-devel-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm perf-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm perf-debuginfo-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm python2-perf-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm python2-perf-debuginfo-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm python3-perf-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm python3-perf-debuginfo-4.19.90-2502.2.0.0315.oe2003sp4.aarch64.rpm bpftool-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm bpftool-debuginfo-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm kernel-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm kernel-debuginfo-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm kernel-debugsource-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm kernel-devel-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm kernel-source-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm kernel-tools-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm kernel-tools-debuginfo-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm kernel-tools-devel-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm perf-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm perf-debuginfo-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm python2-perf-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm python2-perf-debuginfo-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm python3-perf-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm python3-perf-debuginfo-4.19.90-2502.2.0.0315.oe2003sp4.x86_64.rpm kernel-4.19.90-2502.2.0.0315.oe2003sp4.src.rpm In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: Add cancel_work_sync before module remove If we remove the module which will call mpc52xx_spi_remove it will free 'ms' through spi_unregister_controller. while the work ms->work will be used. The sequence of operations that may lead to a UAF bug. Fix it by ensuring that the work is canceled before proceeding with the cleanup in mpc52xx_spi_remove. 2025-02-14 CVE-2024-50051 openEuler-20.03-LTS-SP4 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-02-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1112 In the Linux kernel, the following vulnerability has been resolved: scsi: bfa: Fix use-after-free in bfad_im_module_exit() BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20 Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303 Call Trace: <TASK> dump_stack_lvl+0x95/0xe0 print_report+0xcb/0x620 kasan_report+0xbd/0xf0 __lock_acquire+0x2aca/0x3a20 lock_acquire+0x19b/0x520 _raw_spin_lock+0x2b/0x40 attribute_container_unregister+0x30/0x160 fc_release_transport+0x19/0x90 [scsi_transport_fc] bfad_im_module_exit+0x23/0x60 [bfa] bfad_init+0xdb/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Allocated by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc] bfad_im_module_init+0x17/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x38/0x50 kfree+0x212/0x480 bfad_im_module_init+0x7e/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Above issue happens as follows: bfad_init error = bfad_im_module_init() fc_release_transport(bfad_im_scsi_transport_template); if (error) goto ext; ext: bfad_im_module_exit(); fc_release_transport(bfad_im_scsi_transport_template); --> Trigger double release Don't call bfad_im_module_exit() if bfad_im_module_init() failed. 2025-02-14 CVE-2024-53227 openEuler-20.03-LTS-SP4 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-02-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1112 In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc() bt_sock_alloc() attaches allocated sk object to the provided sock object. If rfcomm_dlc_alloc() fails, we release the sk object, but leave the dangling pointer in the sock object, which may cause use-after-free. Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc(). 2025-02-14 CVE-2024-56604 openEuler-20.03-LTS-SP4 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-02-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1112 In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create() bt_sock_alloc() allocates the sk object and attaches it to the provided sock object. On error l2cap_sock_alloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code. 2025-02-14 CVE-2024-56605 openEuler-20.03-LTS-SP4 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-02-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1112 In the Linux kernel, the following vulnerability has been resolved: drm: adv7511: Fix use-after-free in adv7533_attach_dsi() The host_node pointer was assigned and freed in adv7533_parse_dt(), and later, adv7533_attach_dsi() uses the same. Fix this use-after-free issue by dropping of_node_put() in adv7533_parse_dt() and calling of_node_put() in error path of probe() and also in the remove(). 2025-02-14 CVE-2024-57887 openEuler-20.03-LTS-SP4 High 7.8 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H kernel security update 2025-02-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1112 In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: oss: Fix races at processing SysEx messages OSS sequencer handles the SysEx messages split in 6 bytes packets, and ALSA sequencer OSS layer tries to combine those. It stores the data in the internal buffer and this access is racy as of now, which may lead to the out-of-bounds access. As a temporary band-aid fix, introduce a mutex for serializing the process of the SysEx message packets. 2025-02-14 CVE-2024-57893 openEuler-20.03-LTS-SP4 Medium 5.5 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H kernel security update 2025-02-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1112