{"schema_version":"1.7.2","id":"OESA-2025-1067","modified":"2025-01-17T13:08:15Z","published":"2025-01-17T13:08:15Z","upstream":["CVE-2024-53150","CVE-2024-53155","CVE-2024-53157","CVE-2024-56570","CVE-2024-56603","CVE-2024-56619","CVE-2024-56642","CVE-2024-56662","CVE-2024-56739"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ALSA: usb-audio: Fix out of bounds reads when finding clock sources  The current USB-audio driver code doesn\u0026apos;t check bLength of each descriptor at traversing for clock descriptors.  That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads.  For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal.  When the descriptor length is shorter than expected, it\u0026apos;s skipped in the loop.  For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check.(CVE-2024-53150)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: fix uninitialized value in ocfs2_file_read_iter()  Syzbot has reported the following KMSAN splat:  BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80  ocfs2_file_read_iter+0x9a4/0xf80  __io_read+0x8d4/0x20f0  io_read+0x3e/0xf0  io_issue_sqe+0x42b/0x22c0  io_wq_submit_work+0xaf9/0xdc0  io_worker_handle_work+0xd13/0x2110  io_wq_worker+0x447/0x1410  ret_from_fork+0x6f/0x90  ret_from_fork_asm+0x1a/0x30  Uninit was created at:  __alloc_pages_noprof+0x9a7/0xe00  alloc_pages_mpol_noprof+0x299/0x990  alloc_pages_noprof+0x1bf/0x1e0  allocate_slab+0x33a/0x1250  ___slab_alloc+0x12ef/0x35e0  kmem_cache_alloc_bulk_noprof+0x486/0x1330  __io_alloc_req_refill+0x84/0x560  io_submit_sqes+0x172f/0x2f30  __se_sys_io_uring_enter+0x406/0x41c0  __x64_sys_io_uring_enter+0x11f/0x1a0  x64_sys_call+0x2b54/0x3ba0  do_syscall_64+0xcd/0x1e0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Since an instance of \u0026apos;struct kiocb\u0026apos; may be passed from the block layer with \u0026apos;private\u0026apos; field uninitialized, introduce \u0026apos;ocfs2_iocb_init_rw_locked()\u0026apos; and use it from where \u0026apos;ocfs2_dio_end_io()\u0026apos; might take care, i.e. in \u0026apos;ocfs2_file_read_iter()\u0026apos; and \u0026apos;ocfs2_file_write_iter()\u0026apos;.(CVE-2024-53155)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  firmware: arm_scpi: Check the DVFS OPP count returned by the firmware  Fix a kernel crash with the below call trace when the SCPI firmware returns OPP count of zero.  dvfs_info.opp_count may be zero on some platforms during the reboot test, and the kernel will crash after dereferencing the pointer to kcalloc(info-\u0026gt;count, sizeof(*opp), GFP_KERNEL).    |  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028   |  Mem abort info:   |    ESR = 0x96000004   |    Exception class = DABT (current EL), IL = 32 bits   |    SET = 0, FnV = 0   |    EA = 0, S1PTW = 0   |  Data abort info:   |    ISV = 0, ISS = 0x00000004   |    CM = 0, WnR = 0   |  user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c   |  [0000000000000028] pgd=0000000000000000   |  Internal error: Oops: 96000004 [#1] SMP   |  scpi-hwmon: probe of PHYT000D:00 failed with error -110   |  Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c)   |  CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1   |  Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS   |  pstate: 60000005 (nZCv daif -PAN -UAO)   |  pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]   |  lr : clk_register+0x438/0x720   |  Call trace:   |   scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]   |   devm_clk_hw_register+0x50/0xa0   |   scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi]   |   scpi_clocks_probe+0x528/0x70c [clk_scpi]   |   platform_drv_probe+0x58/0xa8   |   really_probe+0x260/0x3d0   |   driver_probe_device+0x12c/0x148   |   device_driver_attach+0x74/0x98   |   __driver_attach+0xb4/0xe8   |   bus_for_each_dev+0x88/0xe0   |   driver_attach+0x30/0x40   |   bus_add_driver+0x178/0x2b0   |   driver_register+0x64/0x118   |   __platform_driver_register+0x54/0x60   |   scpi_clocks_driver_init+0x24/0x1000 [clk_scpi]   |   do_one_initcall+0x54/0x220   |   do_init_module+0x54/0x1c8   |   load_module+0x14a4/0x1668   |   __se_sys_finit_module+0xf8/0x110   |   __arm64_sys_finit_module+0x24/0x30   |   el0_svc_common+0x78/0x170   |   el0_svc_handler+0x38/0x78   |   el0_svc+0x8/0x340   |  Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820)   |  ---[ end trace 06feb22469d89fa8 ]---   |  Kernel panic - not syncing: Fatal exception   |  SMP: stopping secondary CPUs   |  Kernel Offset: disabled   |  CPU features: 0x10,a0002008   |  Memory Limit: none(CVE-2024-53157)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ovl: Filter invalid inodes with missing lookup function  Add a check to the ovl_dentry_weird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack.(CVE-2024-56570)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: af_can: do not leave a dangling sk pointer in can_create()  On error can_create() frees the allocated sk object, but sock_init_data() has already attached it to the provided sock object. This will leave a dangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()  Syzbot reported that when searching for records in a directory where the inode\u0026apos;s i_size is corrupted and has a large value, memory access outside the folio/page range may occur, or a use-after-free bug may be detected if KASAN is enabled.  This is because nilfs_last_byte(), which is called by nilfs_find_entry() and others to calculate the number of valid bytes of directory data in a page from i_size and the page index, loses the upper 32 bits of the 64-bit size information due to an inappropriate type of local variable to which the i_size value is assigned.  This caused a large byte offset value due to underflow in the end address calculation in the calling nilfs_find_entry(), resulting in memory access that exceeds the folio/page size.  Fix this issue by changing the type of the local variable causing the bit loss from \u0026quot;unsigned int\u0026quot; to \u0026quot;u64\u0026quot;.  The return value of nilfs_last_byte() is also of type \u0026quot;unsigned int\u0026quot;, but it is truncated so as not to exceed PAGE_SIZE and no bit loss occurs, so no change is required.(CVE-2024-56619)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tipc: Fix use-after-free of kernel socket in cleanup_bearer().  syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. [0][1]  When bearer_disable() calls tipc_udp_disable(), cleanup of the UDP kernel socket is deferred by work calling cleanup_bearer().  tipc_net_stop() waits for such works to finish by checking tipc_net(net)-\u0026gt;wq_count.  However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free.  Let\u0026apos;s move the decrement after releasing the socket in cleanup_bearer().  [0]: ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at      sk_alloc+0x438/0x608      inet_create+0x4c8/0xcb0      __sock_create+0x350/0x6b8      sock_create_kern+0x58/0x78      udp_sock_create4+0x68/0x398      udp_sock_create+0x88/0xc8      tipc_udp_enable+0x5e8/0x848      __tipc_nl_bearer_enable+0x84c/0xed8      tipc_nl_bearer_enable+0x38/0x60      genl_family_rcv_msg_doit+0x170/0x248      genl_rcv_msg+0x400/0x5b0      netlink_rcv_skb+0x1dc/0x398      genl_rcv+0x44/0x68      netlink_unicast+0x678/0x8b0      netlink_sendmsg+0x5e4/0x898      ____sys_sendmsg+0x500/0x830  [1]: BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline] BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979  udp_hashslot include/net/udp.h:85 [inline]  udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979  sk_common_release+0xaf/0x3f0 net/core/sock.c:3820  inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437  inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489  __sock_release net/socket.c:658 [inline]  sock_release+0xa0/0x210 net/socket.c:686  cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819  process_one_work kernel/workqueue.c:3229 [inline]  process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310  worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391  kthread+0x531/0x6b0 kernel/kthread.c:389  ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244  Uninit was created at:  slab_free_hook mm/slub.c:2269 [inline]  slab_free mm/slub.c:4580 [inline]  kmem_cache_free+0x207/0xc40 mm/slub.c:4682  net_free net/core/net_namespace.c:454 [inline]  cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647  process_one_work kernel/workqueue.c:3229 [inline]  process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310  worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391  kthread+0x531/0x6b0 kernel/kthread.c:389  ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244  CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer(CVE-2024-56642)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl  Fix an issue detected by syzbot with KASAN:  BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/ core.c:416 [inline] BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0 drivers/acpi/nfit/core.c:459  The issue occurs in cmd_to_func when the call_pkg-\u0026gt;nd_reserved2 array is accessed without verifying that call_pkg points to a buffer that is appropriately sized as a struct nd_cmd_pkg. This can lead to out-of-bounds access and undefined behavior if the buffer does not have sufficient space.  To address this, a check was added in acpi_nfit_ctl() to ensure that buf is not NULL and that buf_len is less than sizeof(*call_pkg) before accessing it. This ensures safe access to the members of call_pkg, including the nd_reserved2 array.(CVE-2024-56662)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  rtc: check if __rtc_read_time was successful in rtc_timer_do_work()  If the __rtc_read_time call fails,, the struct rtc_time tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware.  When calling rtc_tm_to_ktime later, the result may be a very large value (possibly KTIME_MAX). If there are periodic timers in rtc-\u0026gt;timerqueue, they will continually expire, may causing kernel softlockup.(CVE-2024-56739)","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-2501.3.0.0312.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","kernel-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","perf-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2501.3.0.0312.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2501.3.0.0312.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","kernel-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","perf-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2501.3.0.0312.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1067"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53150"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53155"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53157"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56570"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56603"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56619"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56642"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56662"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56739"}],"database_specific":{"severity":"High"}}