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-2122 Final 1.0 1.0 2024-09-14 Initial 2024-09-14 2024-09-14 openEuler SA Tool V1.0 2024-09-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: ibmvnic: free reset-work-item when flushing Fix a tiny memory leak when flushing the reset work queue.(CVE-2022-48905) In the Linux kernel, the following vulnerability has been resolved: xen/netfront: destroy queues before real_num_tx_queues is zeroed xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5 ("net-sysfs: update the queue counts in the unregistration path"), unregister_netdev() indirectly sets real_num_tx_queues to 0. Those two facts together means, that xennet_destroy_queues() called from xennet_remove() cannot do its job, because it's called after unregister_netdev(). This results in kfree-ing queues that are still linked in napi, which ultimately crashes: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 52 Comm: xenwatch Tainted: G W 5.16.10-1.32.fc32.qubes.x86_64+ #226 RIP: 0010:free_netdev+0xa3/0x1a0 Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff <48> 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00 RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050 R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680 FS: 0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0 Call Trace: <TASK> xennet_remove+0x13d/0x300 [xen_netfront] xenbus_dev_remove+0x6d/0xf0 __device_release_driver+0x17a/0x240 device_release_driver+0x24/0x30 bus_remove_device+0xd8/0x140 device_del+0x18b/0x410 ? _raw_spin_unlock+0x16/0x30 ? klist_iter_exit+0x14/0x20 ? xenbus_dev_request_and_reply+0x80/0x80 device_unregister+0x13/0x60 xenbus_dev_changed+0x18e/0x1f0 xenwatch_thread+0xc0/0x1a0 ? do_wait_intr_irq+0xa0/0xa0 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 </TASK> Fix this by calling xennet_destroy_queues() from xennet_uninit(), when real_num_tx_queues is still available. This ensures that queues are destroyed when real_num_tx_queues is set to 0, regardless of how unregister_netdev() was called. Originally reported at https://github.com/QubesOS/qubes-issues/issues/7257(CVE-2022-48914) In the Linux kernel, the following vulnerability has been resolved: usb: gadget: rndis: add spinlock for rndis response list There's no lock for rndis response list. It could cause list corruption if there're two different list_add at the same time like below. It's better to add in rndis_add_response / rndis_free_response / rndis_get_next_response to prevent any race condition on response list. [ 361.894299] [1: irq/191-dwc3:16979] list_add corruption. next->prev should be prev (ffffff80651764d0), but was ffffff883dc36f80. (next=ffffff80651764d0). [ 361.904380] [1: irq/191-dwc3:16979] Call trace: [ 361.904391] [1: irq/191-dwc3:16979] __list_add_valid+0x74/0x90 [ 361.904401] [1: irq/191-dwc3:16979] rndis_msg_parser+0x168/0x8c0 [ 361.904409] [1: irq/191-dwc3:16979] rndis_command_complete+0x24/0x84 [ 361.904417] [1: irq/191-dwc3:16979] usb_gadget_giveback_request+0x20/0xe4 [ 361.904426] [1: irq/191-dwc3:16979] dwc3_gadget_giveback+0x44/0x60 [ 361.904434] [1: irq/191-dwc3:16979] dwc3_ep0_complete_data+0x1e8/0x3a0 [ 361.904442] [1: irq/191-dwc3:16979] dwc3_ep0_interrupt+0x29c/0x3dc [ 361.904450] [1: irq/191-dwc3:16979] dwc3_process_event_entry+0x78/0x6cc [ 361.904457] [1: irq/191-dwc3:16979] dwc3_process_event_buf+0xa0/0x1ec [ 361.904465] [1: irq/191-dwc3:16979] dwc3_thread_interrupt+0x34/0x5c(CVE-2022-48926) In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer: pr_debug("Failed to hot-remove memory at %llx\n", lmb->base_addr); This was found by inspection and confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry.(CVE-2023-52451) In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem.(CVE-2023-52612) In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue(): spin_lock_irqsave(&hsotg->lock, flags); ... if (!urb->hcpriv) { dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n"); goto out; } rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv ... out: spin_unlock_irqrestore(&hsotg->lock, flags); When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are concurrently executed, the NULL check of "urb->hcpriv" can be executed before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL pointer dereference. This possible bug is found by an experimental static analysis tool developed by myself. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported, when my tool analyzes the source code of Linux 6.5. To fix this possible bug, "urb->hcpriv = NULL" should be executed with holding the lock "hsotg->lock". After using this patch, my tool never reports the possible bug, with the kernelconfiguration allyesconfig for x86_64. Because I have no associated hardware, I cannot test the patch in runtime testing, and just verify it according to the code logic.(CVE-2023-52855) In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate() In Google internal bug 265639009 we've received an (as yet) unreproducible crash report from an aarch64 GKI 5.10.149-android13 running device. AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify() with the crash at: ncm_do_notify+0x98/0x270 Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b) Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c] which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c) heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); which calls: ncm_bitrate(NULL) which then calls: gadget_is_superspeed(NULL) which reads ((struct usb_gadget *)NULL)->max_speed and hits a panic. AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C. (remember there's a GKI KABI reservation of 16 bytes in struct work_struct) It's not at all clear to me how this is all supposed to work... but returning 0 seems much better than panic-ing...(CVE-2023-52894) In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame() Fix a use-after-free that occurs in hcd when in_urb sent from pn533_usb_send_frame() is completed earlier than out_urb. Its callback frees the skb data in pn533_send_async_complete() that is used as a transfer buffer of out_urb. Wait before sending in_urb until the callback of out_urb is called. To modify the callback of out_urb alone, separate the complete function of out_urb and ack_urb. Found by a modified version of syzkaller. BUG: KASAN: use-after-free in dummy_timer Call Trace: memcpy (mm/kasan/shadow.c:65) dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352) transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972) arch_static_branch (arch/x86/include/asm/jump_label.h:27) static_key_false (include/linux/jump_label.h:207) timer_expire_exit (include/trace/events/timer.h:127) call_timer_fn (kernel/time/timer.c:1475) expire_timers (kernel/time/timer.c:1519) __run_timers (kernel/time/timer.c:1790) run_timer_softirq (kernel/time/timer.c:1803)(CVE-2023-52907) In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix Virtual Memory mapping boundaries calculation Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access. Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses. Additionally, the calculations have been rewritten in a clearer and more understandable form. [Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)(CVE-2024-42259) In the Linux kernel, the following vulnerability has been resolved: nilfs2: handle inconsistent state in nilfs_btnode_create_block() Syzbot reported that a buffer state inconsistency was detected in nilfs_btnode_create_block(), triggering a kernel bug. It is not appropriate to treat this inconsistency as a bug; it can occur if the argument block address (the buffer index of the newly created block) is a virtual block number and has been reallocated due to corruption of the bitmap used to manage its allocation state. So, modify nilfs_btnode_create_block() and its callers to treat it as a possible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295) In the Linux kernel, the following vulnerability has been resolved: dev/parport: fix the array out-of-bounds risk Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed. Below is the stack trace I encountered during the actual issue: [ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport](CVE-2024-42301) In the Linux kernel, the following vulnerability has been resolved: dma: fix call order in dmam_free_coherent dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation. Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list. If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by destroying the devres entry before freeing the DMA allocation. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03(CVE-2024-43856) In the Linux kernel, the following vulnerability has been resolved: jfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858) In the Linux kernel, the following vulnerability has been resolved: devres: Fix memory leakage caused by driver API devm_free_percpu() It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871) In the Linux kernel, the following vulnerability has been resolved: md/raid5: avoid BUG_ON() while continue reshape after reassembling Currently, mdadm support --revert-reshape to abort the reshape while reassembling, as the test 07revert-grow. However, following BUG_ON() can be triggerred by the test: kernel BUG at drivers/md/raid5.c:6278! invalid opcode: 0000 [#1] PREEMPT SMP PTI irq event stamp: 158985 CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshape_request+0x3f1/0xe60 Call Trace: <TASK> raid5_sync_request+0x43d/0x550 md_do_sync+0xb7a/0x2110 md_thread+0x294/0x2b0 kthread+0x147/0x1c0 ret_from_fork+0x59/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> Root cause is that --revert-reshape update the raid_disks from 5 to 4, while reshape position is still set, and after reassembling the array, reshape position will be read from super block, then during reshape the checking of 'writepos' that is caculated by old reshape position will fail. Fix this panic the easy way first, by converting the BUG_ON() to WARN_ON(), and stop the reshape if checkings fail. Noted that mdadm must fix --revert-shape as well, and probably md/raid should enhance metadata validation as well, however this means reassemble will fail and there must be user tools to fix the wrong metadata.(CVE-2024-43914) 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-2024-2122 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48905 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48914 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48926 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52451 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52612 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52855 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52894 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52907 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42259 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42295 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42301 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-43856 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-43858 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-43871 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-43914 https://nvd.nist.gov/vuln/detail/CVE-2022-48905 https://nvd.nist.gov/vuln/detail/CVE-2022-48914 https://nvd.nist.gov/vuln/detail/CVE-2022-48926 https://nvd.nist.gov/vuln/detail/CVE-2023-52451 https://nvd.nist.gov/vuln/detail/CVE-2023-52612 https://nvd.nist.gov/vuln/detail/CVE-2023-52855 https://nvd.nist.gov/vuln/detail/CVE-2023-52894 https://nvd.nist.gov/vuln/detail/CVE-2023-52907 https://nvd.nist.gov/vuln/detail/CVE-2024-42259 https://nvd.nist.gov/vuln/detail/CVE-2024-42295 https://nvd.nist.gov/vuln/detail/CVE-2024-42301 https://nvd.nist.gov/vuln/detail/CVE-2024-43856 https://nvd.nist.gov/vuln/detail/CVE-2024-43858 https://nvd.nist.gov/vuln/detail/CVE-2024-43871 https://nvd.nist.gov/vuln/detail/CVE-2024-43914 openEuler-20.03-LTS-SP4 bpftool-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm bpftool-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm kernel-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm kernel-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm kernel-debugsource-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm kernel-devel-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm kernel-source-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm kernel-tools-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm kernel-tools-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm kernel-tools-devel-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm perf-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm perf-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm python2-perf-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm python2-perf-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm python3-perf-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm python3-perf-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.aarch64.rpm bpftool-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm bpftool-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm kernel-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm kernel-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm kernel-debugsource-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm kernel-devel-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm kernel-source-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm kernel-tools-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm kernel-tools-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm kernel-tools-devel-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm perf-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm perf-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm python2-perf-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm python2-perf-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm python3-perf-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm python3-perf-debuginfo-4.19.90-2409.3.0.0294.oe2003sp4.x86_64.rpm kernel-4.19.90-2409.3.0.0294.oe2003sp4.src.rpm In the Linux kernel, the following vulnerability has been resolved:ibmvnic: free reset-work-item when flushingFix a tiny memory leak when flushing the reset work queue. 2024-09-14 CVE-2022-48905 openEuler-20.03-LTS-SP4 Low 3.3 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L kernel security update 2024-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122 In the Linux kernel, the following vulnerability has been resolved:xen/netfront: destroy queues before real_num_tx_queues is zeroedxennet_destroy_queues() relies on info->netdev->real_num_tx_queues todelete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5( net-sysfs: update the queue counts in the unregistration path ),unregister_netdev() indirectly sets real_num_tx_queues to 0. Those twofacts together means, that xennet_destroy_queues() called fromxennet_remove() cannot do its job, because it s called afterunregister_netdev(). This results in kfree-ing queues that are stilllinked in napi, which ultimately crashes: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 52 Comm: xenwatch Tainted: G W 5.16.10-1.32.fc32.qubes.x86_64+ #226 RIP: 0010:free_netdev+0xa3/0x1a0 Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff <48> 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00 RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050 R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680 FS: 0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0 Call Trace: <TASK> xennet_remove+0x13d/0x300 [xen_netfront] xenbus_dev_remove+0x6d/0xf0 __device_release_driver+0x17a/0x240 device_release_driver+0x24/0x30 bus_remove_device+0xd8/0x140 device_del+0x18b/0x410 ? _raw_spin_unlock+0x16/0x30 ? klist_iter_exit+0x14/0x20 ? xenbus_dev_request_and_reply+0x80/0x80 device_unregister+0x13/0x60 xenbus_dev_changed+0x18e/0x1f0 xenwatch_thread+0xc0/0x1a0 ? do_wait_intr_irq+0xa0/0xa0 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 </TASK>Fix this by calling xennet_destroy_queues() from xennet_uninit(),when real_num_tx_queues is still available. This ensures that queues aredestroyed when real_num_tx_queues is set to 0, regardless of howunregister_netdev() was called.Originally reported athttps://github.com/QubesOS/qubes-issues/issues/7257 2024-09-14 CVE-2022-48914 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-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122 In the Linux kernel, the following vulnerability has been resolved:usb: gadget: rndis: add spinlock for rndis response listThere s no lock for rndis response list. It could cause list corruptionif there re two different list_add at the same time like below.It s better to add in rndis_add_response / rndis_free_response/ rndis_get_next_response to prevent any race condition on response list.[ 361.894299] [1: irq/191-dwc3:16979] list_add corruption.next->prev should be prev (ffffff80651764d0),but was ffffff883dc36f80. (next=ffffff80651764d0).[ 361.904380] [1: irq/191-dwc3:16979] Call trace:[ 361.904391] [1: irq/191-dwc3:16979] __list_add_valid+0x74/0x90[ 361.904401] [1: irq/191-dwc3:16979] rndis_msg_parser+0x168/0x8c0[ 361.904409] [1: irq/191-dwc3:16979] rndis_command_complete+0x24/0x84[ 361.904417] [1: irq/191-dwc3:16979] usb_gadget_giveback_request+0x20/0xe4[ 361.904426] [1: irq/191-dwc3:16979] dwc3_gadget_giveback+0x44/0x60[ 361.904434] [1: irq/191-dwc3:16979] dwc3_ep0_complete_data+0x1e8/0x3a0[ 361.904442] [1: irq/191-dwc3:16979] dwc3_ep0_interrupt+0x29c/0x3dc[ 361.904450] [1: irq/191-dwc3:16979] dwc3_process_event_entry+0x78/0x6cc[ 361.904457] [1: irq/191-dwc3:16979] dwc3_process_event_buf+0xa0/0x1ec[ 361.904465] [1: irq/191-dwc3:16979] dwc3_thread_interrupt+0x34/0x5c 2024-09-14 CVE-2022-48926 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-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122 In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer: pr_debug("Failed to hot-remove memory at %llx\n", lmb->base_addr); This was found by inspection and confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry. 2024-09-14 CVE-2023-52451 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-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122 In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem. 2024-09-14 CVE-2023-52612 openEuler-20.03-LTS-SP4 None 6.0 AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H kernel security update 2024-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122 In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue(): spin_lock_irqsave(&hsotg->lock, flags); ... if (!urb->hcpriv) { dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n"); goto out; } rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv ... out: spin_unlock_irqrestore(&hsotg->lock, flags); When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are concurrently executed, the NULL check of "urb->hcpriv" can be executed before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL pointer dereference. This possible bug is found by an experimental static analysis tool developed by myself. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported, when my tool analyzes the source code of Linux 6.5. To fix this possible bug, "urb->hcpriv = NULL" should be executed with holding the lock "hsotg->lock". After using this patch, my tool never reports the possible bug, with the kernelconfiguration allyesconfig for x86_64. Because I have no associated hardware, I cannot test the patch in runtime testing, and just verify it according to the code logic. 2024-09-14 CVE-2023-52855 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-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122 In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate() In Google internal bug 265639009 we've received an (as yet) unreproducible crash report from an aarch64 GKI 5.10.149-android13 running device. AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify() with the crash at: ncm_do_notify+0x98/0x270 Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b) Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c] which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c) heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); which calls: ncm_bitrate(NULL) which then calls: gadget_is_superspeed(NULL) which reads ((struct usb_gadget *)NULL)->max_speed and hits a panic. AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C. (remember there's a GKI KABI reservation of 16 bytes in struct work_struct) It's not at all clear to me how this is all supposed to work... but returning 0 seems much better than panic-ing... 2024-09-14 CVE-2023-52894 openEuler-20.03-LTS-SP4 Low 3.9 AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L kernel security update 2024-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122 In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: Wait for out_urb s completion in pn533_usb_send_frame()Fix a use-after-free that occurs in hcd when in_urb sent frompn533_usb_send_frame() is completed earlier than out_urb. Its callbackfrees the skb data in pn533_send_async_complete() that is used as atransfer buffer of out_urb. Wait before sending in_urb until thecallback of out_urb is called. To modify the callback of out_urb alone,separate the complete function of out_urb and ack_urb.Found by a modified version of syzkaller.BUG: KASAN: use-after-free in dummy_timerCall Trace: memcpy (mm/kasan/shadow.c:65) dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352) transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972) arch_static_branch (arch/x86/include/asm/jump_label.h:27) static_key_false (include/linux/jump_label.h:207) timer_expire_exit (include/trace/events/timer.h:127) call_timer_fn (kernel/time/timer.c:1475) expire_timers (kernel/time/timer.c:1519) __run_timers (kernel/time/timer.c:1790) run_timer_softirq (kernel/time/timer.c:1803) 2024-09-14 CVE-2023-52907 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-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122 In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix Virtual Memory mapping boundaries calculation Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access. Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses. Additionally, the calculations have been rewritten in a clearer and more understandable form. [Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417) 2024-09-14 CVE-2024-42259 openEuler-20.03-LTS-SP4 Medium 6.1 AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H kernel security update 2024-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122 In the Linux kernel, the following vulnerability has been resolved: nilfs2: handle inconsistent state in nilfs_btnode_create_block() Syzbot reported that a buffer state inconsistency was detected in nilfs_btnode_create_block(), triggering a kernel bug. It is not appropriate to treat this inconsistency as a bug; it can occur if the argument block address (the buffer index of the newly created block) is a virtual block number and has been reallocated due to corruption of the bitmap used to manage its allocation state. So, modify nilfs_btnode_create_block() and its callers to treat it as a possible filesystem error, rather than triggering a kernel bug. 2024-09-14 CVE-2024-42295 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-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122 In the Linux kernel, the following vulnerability has been resolved:dev/parport: fix the array out-of-bounds riskFixed array out-of-bounds issues caused by sprintfby replacing it with snprintf for safer data copying,ensuring the destination buffer is not overflowed.Below is the stack trace I encountered during the actual issue:[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport][ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYunPGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport] 2024-09-14 CVE-2024-42301 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-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122 In the Linux kernel, the following vulnerability has been resolved:dma: fix call order in dmam_free_coherentdmam_free_coherent() frees a DMA allocation, which makes thefreed vaddr available for reuse, then calls devres_destroy()to remove and free the data structure used to track the DMAallocation. Between the two calls, it is possible for aconcurrent task to make an allocation with the same vaddrand add it to the devres list.If this happens, there will be two entries in the devres listwith the same vaddr and devres_destroy() can free the wrongentry, triggering the WARN_ON() in dmam_match.Fix by destroying the devres entry before freeing the DMAallocation. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 2024-09-14 CVE-2024-43856 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-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122 In the Linux kernel, the following vulnerability has been resolved:jfs: Fix array-index-out-of-bounds in diFree 2024-09-14 CVE-2024-43858 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-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122 In the Linux kernel, the following vulnerability has been resolved:devres: Fix memory leakage caused by driver API devm_free_percpu()It will cause memory leakage when use driver API devm_free_percpu()to free memory allocated by devm_alloc_percpu(), fixed by usingdevres_release() instead of devres_destroy() within devm_free_percpu(). 2024-09-14 CVE-2024-43871 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-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122 In the Linux kernel, the following vulnerability has been resolved:md/raid5: avoid BUG_ON() while continue reshape after reassemblingCurrently, mdadm support --revert-reshape to abort the reshape whilereassembling, as the test 07revert-grow. However, following BUG_ON()can be triggerred by the test:kernel BUG at drivers/md/raid5.c:6278!invalid opcode: 0000 [#1] PREEMPT SMP PTIirq event stamp: 158985CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94RIP: 0010:reshape_request+0x3f1/0xe60Call Trace: <TASK> raid5_sync_request+0x43d/0x550 md_do_sync+0xb7a/0x2110 md_thread+0x294/0x2b0 kthread+0x147/0x1c0 ret_from_fork+0x59/0x70 ret_from_fork_asm+0x1a/0x30 </TASK>Root cause is that --revert-reshape update the raid_disks from 5 to 4,while reshape position is still set, and after reassembling the array,reshape position will be read from super block, then during reshape thechecking of writepos that is caculated by old reshape position willfail.Fix this panic the easy way first, by converting the BUG_ON() toWARN_ON(), and stop the reshape if checkings fail.Noted that mdadm must fix --revert-shape as well, and probably md/raidshould enhance metadata validation as well, however this meansreassemble will fail and there must be user tools to fix the wrongmetadata. 2024-09-14 CVE-2024-43914 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-09-14 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2122