An update for kernel is now available for openEuler-20.03-LTS-SP4 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2024-2294 Final 1.0 1.0 2024-10-25 Initial 2024-10-25 2024-10-25 openEuler SA Tool V1.0 2024-10-25 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: ipv6: sr: fix invalid unregister error path The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path.(CVE-2024-38612) In the Linux kernel, the following vulnerability has been resolved: driver core: Fix uevent_show() vs driver detach race uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ #275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1].(CVE-2024-44952) In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Fix underflows seen when writing limit attributes DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46757) In the Linux kernel, the following vulnerability has been resolved: ELF: fix kernel.randomize_va_space double read ELF loader uses "randomize_va_space" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences. Issue exactly one load for consistent value across one exec.(CVE-2024-46826) 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 critical. 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. Critical kernel https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2294 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38612 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-44952 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-46757 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-46826 https://nvd.nist.gov/vuln/detail/CVE-2024-38612 https://nvd.nist.gov/vuln/detail/CVE-2024-44952 https://nvd.nist.gov/vuln/detail/CVE-2024-46757 https://nvd.nist.gov/vuln/detail/CVE-2024-46826 openEuler-20.03-LTS-SP4 bpftool-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm bpftool-debuginfo-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm kernel-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm kernel-debuginfo-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm kernel-debugsource-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm kernel-devel-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm kernel-source-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm kernel-tools-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm kernel-tools-debuginfo-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm kernel-tools-devel-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm perf-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm perf-debuginfo-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm python2-perf-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm python2-perf-debuginfo-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm python3-perf-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm python3-perf-debuginfo-4.19.90-2410.3.0.0300.oe2003sp4.aarch64.rpm bpftool-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm bpftool-debuginfo-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm kernel-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm kernel-debuginfo-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm kernel-debugsource-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm kernel-devel-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm kernel-source-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm kernel-tools-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm kernel-tools-debuginfo-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm kernel-tools-devel-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm perf-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm perf-debuginfo-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm python2-perf-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm python2-perf-debuginfo-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm python3-perf-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm python3-perf-debuginfo-4.19.90-2410.3.0.0300.oe2003sp4.x86_64.rpm kernel-4.19.90-2410.3.0.0300.oe2003sp4.src.rpm In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix invalid unregister error pathThe error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNELis not defined. In that case if seg6_hmac_init() fails, thegenl_unregister_family() isn t called.This issue exist since commit 46738b1317e1 ( ipv6: sr: add option to controllwtunnel support ), and commit 5559cea2d5aa ( ipv6: sr: fix possibleuse-after-free and null-ptr-deref ) replaced unregister_pernet_subsys()with genl_unregister_family() in this error path. 2024-10-25 CVE-2024-38612 openEuler-20.03-LTS-SP4 Critical 9.8 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H kernel security update 2024-10-25 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2294 In the Linux kernel, the following vulnerability has been resolved: driver core: Fix uevent_show() vs driver detach race uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ #275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event. Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. 2024-10-25 CVE-2024-44952 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 2024-10-25 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2294 In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Fix underflows seen when writing limit attributes DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. 2024-10-25 CVE-2024-46757 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 2024-10-25 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2294 In the Linux kernel, the following vulnerability has been resolved: ELF: fix kernel.randomize_va_space double read ELF loader uses "randomize_va_space" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences. Issue exactly one load for consistent value across one exec. 2024-10-25 CVE-2024-46826 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 2024-10-25 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2294