2024-02-29
New_entries
CVE-2020-36776
description
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/cpufreq_cooling: Fix slab OOB issue Slab OOB issue is scanned by KASAN in cpu_power_to_freq(). If power is limited below the power of OPP0 in EM table, it will cause slab out-of-bound issue with negative array index. Return the lowest frequency if limited power cannot found a suitable OPP in EM table to fix this issue. Backtrace: [] die+0x104/0x5ac [] bug_handler+0x64/0xd0 [] brk_handler+0x160/0x258 [] do_debug_exception+0x248/0x3f0 [] el1_dbg+0x14/0xbc [] __kasan_report+0x1dc/0x1e0 [] kasan_report+0x10/0x20 [] __asan_report_load8_noabort+0x18/0x28 [] cpufreq_power2state+0x180/0x43c [] power_actor_set_power+0x114/0x1d4 [] allocate_power+0xaec/0xde0 [] power_allocator_throttle+0x3ec/0x5a4 [] handle_thermal_trip+0x160/0x294 [] thermal_zone_device_check+0xe4/0x154 [] process_one_work+0x5e4/0xe28 [] worker_thread+0xa4c/0xfac [] kthread+0x33c/0x358 [] ret_from_fork+0xc/0x18
description
在Linux内核中,已解决以下漏洞:thermal/drivers/cpufreq_colling:修复slab OOB问题slab OOB问题由KASAN在cpu_power_to_freq()中扫描。如果功率被限制在EM表中OPP0的功率以下,则会导致负数组索引的板越界问题。如果有限的功率在EM表中找不到合适的OPP来解决此问题,则返回最低频率。回溯:[]die+0x104/0x5ac[]bug_handler+0x64/0xd0[]brk_handler+0x160/0x258[]do_debug_exception+0x248/0x3f0[]el1_dbg+0x14/0xbc[<ffffff d 02 d75 d1d4>]__kasan_report+0x1dc/0x1e0[]kasan_report+0x10/0x20[<ffffff d02d75定义8>]__asan_port_load8_noabort+0x18/0x28[<ffff d02定义6fce5c>]cpufreq_power2state+0x180/0x43c[]power_actor_set_power+0x114/0x1d4[]allocate_power+0xaec/0xde0[<ffFFff d02 e 6f9f80>]power _allocate_throttle+0x3ec/0x5a4[<FFFFff d02e 6ea888>]handle_thermal_trip+0x160/0x294[]thermal_zone_device_check+0x4/0x154[]process_one_work+0x5e4/0xe28[]worker_thread+0x4c/0xfac[]kthread+0x3c/0x358[]ret_from_fork+0xc/0x18
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/34ab17cc6c2c1ac93d7e5d53bb972df9a968f085
- https://git.kernel.org/stable/c/6bf443acf6ca4f666d0e4225614ba9993a3aa1a9
- https://git.kernel.org/stable/c/876a5f33e5d961d879c5436987c09b3d9ef70379
- https://git.kernel.org/stable/c/c24a20912eef00587416628149c438e885eb1304
CVE-2020-36777
description
In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: Fix memory leak in dvb_media_device_free() dvb_media_device_free() is leaking memory. Free dvbdev->adapter->conn
before setting it to NULL, as documented in include/media/media-device.h: “The media_entity instance itself must be freed explicitly by the driver if required.”
description
在Linux内核中,已解决以下漏洞:media:dvbdev:修复dvb_media_device_free()中的内存泄漏dvb_media/device_freee()正在泄漏内存。在将dvbdev->adapter->conn
设置为NULL之前释放它,如include/media/media device.h中所述:“如果需要,驱动程序必须显式释放media_entity实例本身。”
cvss | epss | percentile |
---|---|---|
None | 0.04% | 10.59% |
references
- https://git.kernel.org/stable/c/06854b943e0571ccbd7ad0a529babed1a98ff275
- https://git.kernel.org/stable/c/32168ca1f123316848fffb85d059860adf3c409f
- https://git.kernel.org/stable/c/43263fd43083e412311fa764cd04a727b0c6a749
- https://git.kernel.org/stable/c/9185b3b1c143b8da409c19ac5a785aa18d67a81b
- https://git.kernel.org/stable/c/9ad15e214fcd73694ea51967d86055f47b802066
- https://git.kernel.org/stable/c/bf9a40ae8d722f281a2721779595d6df1c33a0bf
- https://git.kernel.org/stable/c/cd89f79be5d553c78202f686e8e4caa5fbe94e98
- https://git.kernel.org/stable/c/cede24d13be6c2a62be6d7ceea63c2719b0cfa82
CVE-2021-46907
description
In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Dont use vcpu->run->internal.ndata as an array index __vmx_handle_exit() uses vcpu->run->internal.ndata as an index for an array access. Since vcpu->run is (can be) mapped to a user address space with a writer permission, the ndata could be updated by the user process at anytime (the user process can set it to outside the bounds of the array). So, it is not safe that __vmx_handle_exit() uses the ndata that way.
description
在Linux内核中,已解决以下漏洞:KVM:VMX:不要使用vcpu->run->internal.ndata作为数组索引__VMX_handle_exit()使用vcpu->run->internal_ndata作为阵列访问的索引。由于vcpu->run(可以)映射到具有写入程序权限的用户地址空间,因此用户进程可以随时更新数据表(用户进程可以将其设置为数组边界之外)。因此,__vmx_handle_exit()以这种方式使用数据塔是不安全的。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/04c4f2ee3f68c9a4bf1653d15f1a9a435ae33f7a
- https://git.kernel.org/stable/c/7f64753835a78c7d2cc2932a5808ef3b7fd4c050
- https://git.kernel.org/stable/c/ce541d7b59566a0d94c7c99bfb5d34b050e6af70
CVE-2021-46908
description
In the Linux kernel, the following vulnerability has been resolved: bpf: Use correct permission flag for mixed signed bounds arithmetic We forbid adding unknown scalars with mixed signed bounds due to the spectre v1 masking mitigation. Hence this also needs bypass_spec_v1 flag instead of allow_ptr_leaks.
description
在Linux内核中,已解决以下漏洞:bpf:对混合有符号边界算法使用正确的权限标志由于spectre v1屏蔽缓解,我们禁止添加具有混合有符号界限的未知标量。因此,这也需要bypass_spec_v1标志,而不是allow_ptr_leaks。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/4ccdc6c6cae38b91c871293fb0ed8c6845a61b51
- https://git.kernel.org/stable/c/4f3ff11204eac0ee23acf64deecb3bad7b0db0c6
- https://git.kernel.org/stable/c/9601148392520e2e134936e76788fc2a6371e7be
CVE-2021-46909
description
In the Linux kernel, the following vulnerability has been resolved: ARM: footbridge: fix PCI interrupt mapping Since commit 30fdfb929e82 (“PCI: Add a call to pci_assign_irq() in pci_device_probe()”), the PCI code will call the IRQ mapping function whenever a PCI driver is probed. If these are marked as __init, this causes an oops if a PCI driver is loaded or bound after the kernel has initialised.
description
在Linux内核中,以下漏洞已被解决:ARM:footbridge:修复PCI中断映射由于提交了30fdfb929e82(“PCI:在PCI_device_probe()中添加对PCI_assign_irq()的调用”),每当探测PCI驱动程序时,PCI代码都会调用irq映射函数。如果这些被标记为__init,那么如果在内核初始化后加载或绑定PCI驱动程序,就会导致oops。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 8.10% |
references
- https://git.kernel.org/stable/c/1fc087fdb98d556b416c82ed6e3964a30885f47a
- https://git.kernel.org/stable/c/2643da6aa57920d9159a1a579fb04f89a2b0d29a
- https://git.kernel.org/stable/c/30e3b4f256b4e366a61658c294f6a21b8626dda7
- https://git.kernel.org/stable/c/532747fd5c7aaa17ee5cf79f3e947c31eb0e35cf
- https://git.kernel.org/stable/c/871b569a3e67f570df9f5ba195444dc7c621293b
- https://git.kernel.org/stable/c/c3efce8cc9807339633ee30e39882f4c8626ee1d
CVE-2021-46910
description
In the Linux kernel, the following vulnerability has been resolved: ARM: 9063/1: mm: reduce maximum number of CPUs if DEBUG_KMAP_LOCAL is enabled The debugging code for kmap_local() doubles the number of per-CPU fixmap slots allocated for kmap_local(), in order to use half of them as guard regions. This causes the fixmap region to grow downwards beyond the start of its reserved window if the supported number of CPUs is large, and collide with the newly added virtual DT mapping right below it, which is obviously not good. One manifestation of this is EFI boot on a kernel built with NR_CPUS=32 and CONFIG_DEBUG_KMAP_LOCAL=y, which may pass the FDT in highmem, resulting in block entries below the fixmap region that the fixmap code misidentifies as fixmap table entries, and subsequently tries to dereference using a phys-to-virt translation that is only valid for lowmem. This results in a cryptic splat such as the one below. ftrace: allocating 45548 entries in 89 pages 8<— cut here — Unable to handle kernel paging request at virtual address fc6006f0 pgd = (ptrval) [fc6006f0] *pgd=80000040207003, *pmd=00000000 Internal error: Oops: a06 [#1] SMP ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.11.0+ #382 Hardware name: Generic DT based system PC is at cpu_ca15_set_pte_ext+0x24/0x30 LR is at __set_fixmap+0xe4/0x118 pc : [] lr : [] psr: 400000d3 sp : c1601ed8 ip : 00400000 fp : 00800000 r10: 0000071f r9 : 00421000 r8 : 00c00000 r7 : 00c00000 r6 : 0000071f r5 : ffade000 r4 : 4040171f r3 : 00c00000 r2 : 4040171f r1 : c041ac78 r0 : fc6006f0 Flags: nZcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none Control: 30c5387d Table: 40203000 DAC: 00000001 Process swapper (pid: 0, stack limit = 0x(ptrval)) So lets limit CONFIG_NR_CPUS to 16 when CONFIG_DEBUG_KMAP_LOCAL=y. Also, fix the BUILD_BUG_ON() check that was supposed to catch this, by checking whether the region grows below the start address rather than above the end address.
description
在Linux内核中,已解决以下漏洞:ARM:9063/1:mm:如果启用了DEBUG_KMAP_LOCAL,则减少CPU的最大数量。KMAP_LOCAL()的调试代码将为KMAP_LOCAL()分配的每个CPU的fixmap插槽数增加一倍,以便将其中一半用作保护区域。如果支持的CPU数量很大,这会导致fixmap区域向下增长,超过其保留窗口的起点,并与其正下方新添加的虚拟DT映射发生冲突,这显然是不好的。这种情况的一种表现是在NR_CPUS=32和CONFIG_DEBUG_KMAP_LOCAL=y构建的内核上进行EFI引导,这可能会在highmem中传递FDT,导致fixmap代码错误地将其识别为fixmap表项的fixmap区域下方的块项,并随后尝试使用仅对lowmem有效的phys-to-virt转换来取消引用。这导致了一个神秘的飞溅,比如下面的那个。ftrace:在89页中分配45548个条目8<—此处剪切—无法处理虚拟地址fc6006f0处的内核分页请求pgd=(ptrval)[fc6006f0]*pgd=80000040207003,*pmd=000000000内部错误:错误:a06[#1]SMP ARM模块链接在:CPU:0 PID:0通信:交换未受污染5.11.0+#382硬件名称:基于通用DT的系统PC位于CPU_ca15_set_pte_ext+0x24/0x30 LR位于__set_fixmap+0xe4/0x118 PC:[]LR:[<c 04189d8>]psr:400000d3 sp:c1601d8 ip:0400000fp:000000r10:0000071f r9:00421000 r8:00c00000r7:00c00000r 6:0000071f r 5:ffade000 r4:4040171f r3:00c00000r2:4040171fr1:c041ac78 r0:fc6006f0标志:nZcv IRQ关闭FIQ关闭模式SVC_32 ISA ARM段无控制:30c5387d表:40203000 DAC:00000000 1进程交换程序(pid:0,堆栈限制=0x(ptrval))因此,当CONFIG_DEBUG_KMAP_LOCAL=y时,让我们将CONFIG_NR_CPUS限制为16。此外,通过检查区域是否增长到起始地址以下而不是结束地址以上,修复本应捕获此问题的BUILD_BUG_ON()检查。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://git.kernel.org/stable/c/5965ac11b1d5fcb38464728931649cd9df79c7c9
- https://git.kernel.org/stable/c/d624833f5984d484c5e3196f34b926f9e71dafee
CVE-2021-46911
description
In the Linux kernel, the following vulnerability has been resolved: ch_ktls: Fix kernel panic Taking page refcount is not ideal and causes kernel panic sometimes. Its better to take tx_ctx lock for the complete skb transmit, to avoid page cleanup if ACK received in middle.
description
在Linux内核中,已解决以下漏洞:ch_ktls:修复内核死机获取页面引用计数不理想,有时会导致内核死机。最好对完整的skb传输使用tx_ctx锁,以避免在中间接收到ACK时进行页面清理。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/1a73e427b824133940c2dd95ebe26b6dce1cbf10
- https://git.kernel.org/stable/c/8348665d4181c68b0ca1205b48e1753d78bc810f
- https://git.kernel.org/stable/c/8d5a9dbd2116a852f8f0f91f6fbc42a0afe1091f
CVE-2021-46912
description
In the Linux kernel, the following vulnerability has been resolved: net: Make tcp_allowed_congestion_control readonly in non-init netns Currently, tcp_allowed_congestion_control is global and writable; writing to it in any net namespace will leak into all other net namespaces. tcp_available_congestion_control and tcp_allowed_congestion_control are the only sysctls in ipv4_net_table (the per-netns sysctl table) with a NULL data pointer; their handlers (proc_tcp_available_congestion_control and proc_allowed_congestion_control) have no other way of referencing a struct net. Thus, they operate globally. Because ipv4_net_table does not use designated initializers, there is no easy way to fix up this one “bad” table entry. However, the data pointer updating logic shouldnt be applied to NULL pointers anyway, so we instead force these entries to be read-only. These sysctls used to exist in ipv4_table (init-net only), but they were moved to the per-net ipv4_net_table, presumably without realizing that tcp_allowed_congestion_control was writable and thus introduced a leak. Because the intent of that commit was only to know (i.e. read) “which congestion algorithms are available or allowed”, this read-only solution should be sufficient. The logic added in recent commit 31c4d2f160eb: (“net: Ensure net namespace isolation of sysctls”) does not and cannot check for NULL data pointers, because other table entries (e.g. /proc/sys/net/netfilter/nf_log/) have .data=NULL but use other methods (.extra2) to access the struct net.
description
在Linux内核中,以下漏洞已被解决:net:使tcp_allowed_congestion_control在非init netns中只读。当前,tcp_allowed _congestion-control是全局可写的;在任何网络名称空间中写入它都会泄漏到所有其他网络名称空间。tcp_available_congestion_control和tcp_allowed_congestion-control是ipv4_net_table(每个netns的sysctl表)中唯一具有NULL数据指针的sysctls;它们的处理程序(proc_tcp_available_contension_control和proc_allowed_contension-control)没有其他引用结构网的方法。因此,它们在全球范围内运作。因为ipv4_net_table不使用指定的初始化器,所以没有简单的方法来修复这一个“坏”的表条目。然而,数据指针更新逻辑无论如何都不应该应用于NULL指针,因此我们强制这些条目为只读。这些sysctl曾经存在于ipv4_table中(仅限init-net),但它们被移动到了每网ipv4_net_table中,可能没有意识到tcp_allowed_contension_control是可写的,因此引入了泄漏。因为提交的目的只是知道(即读取)“哪些拥塞算法可用或允许”,所以这种只读解决方案应该足够了。在最近的提交31c4d2f160eb:(“net:确保sysctls的网络命名空间隔离”)中添加的逻辑不会也不能检查NULL数据指针,因为其他表项(例如/proc/sys/net/netfilter/nf_log/)具有.data=NULL,但使用其他方法(.extra2)访问结构网络。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/1ccdf1bed140820240e383ba0accc474ffc7f006
- https://git.kernel.org/stable/c/35d7491e2f77ce480097cabcaf93ed409e916e12
- https://git.kernel.org/stable/c/97684f0970f6e112926de631fdd98d9693c7e5c1
CVE-2021-46913
description
In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: clone set element expression template memcpy() breaks when using connlimit in set elements. Use nft_expr_clone() to initialize the connlimit expression list, otherwise connlimit garbage collector crashes when walking on the list head copy. [ 493.064656] Workqueue: events_power_efficient nft_rhash_gc [nf_tables] [ 493.064685] RIP: 0010:find_or_evict+0x5a/0x90 [nf_conncount] [ 493.064694] Code: 2b 43 40 83 f8 01 77 0d 48 c7 c0 f5 ff ff ff 44 39 63 3c 75 df 83 6d 18 01 48 8b 43 08 48 89 de 48 8b 13 48 8b 3d ee 2f 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 03 48 83 [ 493.064699] RSP: 0018:ffffc90000417dc0 EFLAGS: 00010297 [ 493.064704] RAX: 0000000000000000 RBX: ffff888134f38410 RCX: 0000000000000000 [ 493.064708] RDX: 0000000000000000 RSI: ffff888134f38410 RDI: ffff888100060cc0 [ 493.064711] RBP: ffff88812ce594a8 R08: ffff888134f38438 R09: 00000000ebb9025c [ 493.064714] R10: ffffffff8219f838 R11: 0000000000000017 R12: 0000000000000001 [ 493.064718] R13: ffffffff82146740 R14: ffff888134f38410 R15: 0000000000000000 [ 493.064721] FS: 0000000000000000(0000) GS:ffff88840e440000(0000) knlGS:0000000000000000 [ 493.064725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 493.064729] CR2: 0000000000000008 CR3: 00000001330aa002 CR4: 00000000001706e0 [ 493.064733] Call Trace: [ 493.064737] nf_conncount_gc_list+0x8f/0x150 [nf_conncount] [ 493.064746] nft_rhash_gc+0x106/0x390 [nf_tables]
description
在Linux内核中,已解决以下漏洞:netfilter:nftables:clone set元素表达式模板memcpy()在set元素中使用connlimit时中断。使用nft_expr_clone()初始化connlimit表达式列表,否则connlimite垃圾收集器在列表头副本上行走时崩溃。[493.064656]工作队列:events_power_efficient nft_rhash_gc[nf_tables][493.064685]RIP:0010:find_or_reject+0x5a/0x90[nf_conncount][493.064694]代码:2b 43 40 83 f8 01 77 0d 48 c7 c0 f5 ff ff ff 44 39 63 3c 75 df 83 6d 18 01 48 8b 43 08 48 89 de 48 8b 13 48 8b 3d ee 2f 00<48>89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 03 48 83[493.064699]RSP:0018:ffffc90000417dc0 EFLAGS:000010297[493.064704]RAX:00000000000000000 RBX:ffffff888134f38410 RCX:000000000000000[493.064700 8]RDX:000000000 RSI:ffff888134 f38410 RDI:ffffff888 100060cc0[493.064711]RBP:ffff88812ce594a8 R08:ffffffff 888134f38438 R09:00000000 ebb9025c[493.06.4714]R10:ffffff 8219f838 R11:0000000000000017 R12:0000000000000001[493.064718]R13:ffffffff 82146740 R14:ffff888134f38410 R15:0000000000000000[493.064721]FS:0000000000000000(0000)GS:ffff88840e440000(0000)knlGS:000000000000000000000000[493.064725]CS:0010 DS:0000 ES:0000 CR0:00000000 80050033[493.06479]CR2:000000000000000 8 CR3:0000000 1330a002 CR4:0000000000 1706e0[493.064733]调用跟踪:[493.064717]nf_conncount_gc_list+0x8f/0x150[nf_conncount][493.064746]nft_rhash_gc+0x106/0x390[nf_tables]
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/47d8de3c226574a3ddb8b87d0c152028d1bafef4
- https://git.kernel.org/stable/c/4d8f9065830e526c83199186c5f56a6514f457d2
- https://git.kernel.org/stable/c/e51ff3ffc316377cca21de8b80404eed0c37b3c3
CVE-2021-46914
description
In the Linux kernel, the following vulnerability has been resolved: ixgbe: fix unbalanced device enable/disable in suspend/resume pci_disable_device() called in __ixgbe_shutdown() decreases dev->enable_cnt by 1. pci_enable_device_mem() which increases dev->enable_cnt by 1, was removed from ixgbe_resume() in commit 6f82b2558735 (“ixgbe: use generic power management”). This caused unbalanced increase/decrease. So add pci_enable_device_mem() back. Fix the following call trace. ixgbe 0000:17:00.1: disabling already-disabled device Call Trace: __ixgbe_shutdown+0x10a/0x1e0 [ixgbe] ixgbe_suspend+0x32/0x70 [ixgbe] pci_pm_suspend+0x87/0x160 ? pci_pm_freeze+0xd0/0xd0 dpm_run_callback+0x42/0x170 __device_suspend+0x114/0x460 async_suspend+0x1f/0xa0 async_run_entry_fn+0x3c/0xf0 process_one_work+0x1dd/0x410 worker_thread+0x34/0x3f0 ? cancel_delayed_work+0x90/0x90 kthread+0x14c/0x170 ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x30
description
在Linux内核中,已解决以下漏洞:ixgbe:fix在__ixgbe_shutdown()中调用的suspend/resume pci_disable_device()中修复不平衡的设备启用/禁用使dev->enable_cnt减少1。pci_enable_device_mem()将dev->enable_cnt增加1,已从提交6f82b2558735中的ixgbe_resume()中删除(“ixgbe:使用通用电源管理”)。这导致了不平衡的增加/减少。因此,请重新添加pci_enable_device_mem()。修复以下调用跟踪。ixgbe 0000:17:00.1:禁用已禁用的设备调用跟踪:__ixgbe_shutdown+0x10a/0x1e0[ixgbe]ixgbe_suspend+0x32/0x70[ixgbe]pci_pm_suspend+0x87/0x160?pci_pm_freeze+0xd0/0xd0 dpm_run_callback+0x42/0x170__设备暂停+0x114/0x460异步暂停+0x1f/0xa0异步运行控制-fn+0x3c/0xf0进程_工作+0x1dd/0x410工作线程+0x34/0x3f0?cancel_delayerd_work+0x90/0x90 k线程+0x14c/0x170?kthread_park+0x90/0x90 ret_from_fork+0x1f/0x30
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/be07581aacae7cd0a073afae8e8862032f794309
- https://git.kernel.org/stable/c/debb9df311582c83fe369baa35fa4b92e8a9c58a
- https://git.kernel.org/stable/c/f1b4be4a753caa4056496f679d70550d0c11a264
CVE-2021-46915
description
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_limit: avoid possible divide error in nft_limit_init div_u64() divides u64 by u32. nft_limit_init() wants to divide u64 by u64, use the appropriate math function (div64_u64) divide error: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8390 Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:div_u64_rem include/linux/math64.h:28 [inline] RIP: 0010:div_u64 include/linux/math64.h:127 [inline] RIP: 0010:nft_limit_init+0x2a2/0x5e0 net/netfilter/nft_limit.c:85 Code: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00 00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3 9e 22 fa 48 8d 7d 48 48 b8 00 00 00 00 00 RSP: 0018:ffffc90009447198 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000200000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff875152e6 RDI: 0000000000000003 RBP: ffff888020f80908 R08: 0000200000000000 R09: 0000000000000000 R10: ffffffff875152d8 R11: 0000000000000000 R12: ffffc90009447270 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 000000000097a300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200001c4 CR3: 0000000026a52000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [inline] nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713 nft_set_elem_expr_alloc+0x27/0x280 net/netfilter/nf_tables_api.c:5160 nf_tables_newset+0x1997/0x3150 net/netfilter/nf_tables_api.c:4321 nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:580 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae
description
在Linux内核中,以下漏洞已得到解决:netfilter:nft_limit:nft_limit_init div_u64()将u64除以u32,以避免可能出现的除法错误。nft_limit_init()想要用u64除以u64,使用适当的数学函数(div64_u64RIP:0010:nft_limit_init+0x2a2/0x5e0 net/netfilter/nft_limit。c:85代码:ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00 e8 ea 9 e 22 fa 4c 0f f3 45 89 ed 31 d2 4c 89 f0<49>f7 f5 49 89 c6 e8 d3 9e 22 fa 48 8d 48 b8 00 00 00 00 00RSP:0018:ffffffc90009447198 EFLAGS:000010246 RAX:000000000 RBX:0000200000000000 RCX:00000000000000000 RDX:000000000000000 RSI:ffffffff 875152e6 RDI:000000000000000 3 RBP:ffff888020f80908 R08:0000200000000000 R09:000000000000000000000000 R10:fffffffff 875152d8 R11:00000000000000000000000000000000R12:ffffc90009447270 R13:0000000000000000 R14:0000000000000000 R15:000000000000000000000000FS:0000000000097a300(0000)GS:fffff8880b9d00000(0000)knlGS:0000000000000000 CS:0010 DS:0000 ES:0000 CR0:00000000 80050033 CR2:00000000 200001c4 CR3:00000000 26a52000 CR4:0000000000 1506e0 DR0:0000000000000000 DR1:00000000 DR2:00000000 DR6:00000000 fffe0f0 DR7:0000000000000400调用跟踪:nf_tables_newexpr net/netfilter/nf_tables_api.c:2675[inline]nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713 nft_set_e lem_expr_alloc+0x27/0x280 net/nf_filter/nf_tables_api。c:5160 nf_tables_newset+0x1997/0x3150 net/nffilter/nf_ttables_api。c:\4321 nfnetlink_rcv_batch+0x85a/0x21b0 net/nfnetlink。c:456 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink。c:580[inline]nfnetlink-rcv+0x3af/0x420 net/nfcetlink.c:598 netlink_unicast_kernel net/netlink/af_netlink.c:1312[inline]netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af _netlink.c:1927 sock_sendmsg_nosec net/socket.c:654[iinline]sock_sendmsg+0xcf/0x120 net/socket。c:674 ____sys_sendmsg+0x6e8/0x810 net/sockets。c:2350 ___sys_send msg+0xf3/0x170 net/socket。c:2404 __sys_send msg+0xe5/0x1b0 net/socklet。c:2433 do_syscall_64+0x2d/0x70 arch/x6/entry/common。c:46 entry_syscall_64_after_hwframe+0x44/0xae
cvss | epss | percentile |
---|---|---|
None | 0.04% | 8.10% |
references
- https://git.kernel.org/stable/c/01fb1626b620cb37a65ad08e0f626489e8f042ef
- https://git.kernel.org/stable/c/1bb3ee4259936cc3b2d80a4a480bbb4868575071
- https://git.kernel.org/stable/c/9065ccb9ec92c5120e7e97958397ebdb454f23d6
- https://git.kernel.org/stable/c/b895bdf5d643b6feb7c60856326dd4feb6981560
- https://git.kernel.org/stable/c/dc1732baa9da5b68621586bf8636ebbc27dc62d2
- https://git.kernel.org/stable/c/fadd3c4afdf3d4c21f4d138502f8b76334987e26
CVE-2021-46916
description
In the Linux kernel, the following vulnerability has been resolved: ixgbe: Fix NULL pointer dereference in ethtool loopback test The ixgbe driver currently generates a NULL pointer dereference when performing the ethtool loopback test. This is due to the fact that there isnt a q_vector associated with the test ring when it is setup as interrupts are not normally added to the test rings. To address this I have added code that will check for a q_vector before returning a napi_id value. If a q_vector is not present it will return a value of 0.
description
在Linux内核中,已解决以下漏洞:ixgbe:修复ethtool环回测试中的NULL指针取消引用ixgbe驱动程序当前在执行ethtool回送测试时生成NULL指针取消参考。这是因为在设置测试环时没有与测试环相关的q_vector,因为中断通常不会添加到测试环中。为了解决这个问题,我添加了一些代码,这些代码将在返回napi_id值之前检查q_vector。如果不存在q_vector,它将返回值0。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://git.kernel.org/stable/c/31166efb1cee348eb6314e9c0095d84cbeb66b9d
- https://git.kernel.org/stable/c/758d19098df4b0bbca9f40d6ae6c82c9c18b9bba
CVE-2021-46917
description
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix wq cleanup of WQCFG registers A pre-release silicon erratum workaround where wq reset does not clear WQCFG registers was leaked into upstream code. Use wq reset command instead of blasting the MMIO region. This also address an issue where we clobber registers in future devices.
description
在Linux内核中,以下漏洞已被解决:dmaengine:idxd:fix WQCFG寄存器的wq清除一个预发布的硅错误解决方案,其中wq重置无法清除WQCFG注册表,该解决方案已泄漏到上游代码中。使用wq重置命令,而不是爆破MMIO区域。这也解决了我们在未来设备中破坏寄存器的问题。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/e5eb9757fe4c2392e069246ae78badc573af1833
- https://git.kernel.org/stable/c/ea9aadc06a9f10ad20a90edc0a484f1147d88a7a
- https://git.kernel.org/stable/c/f7dc8f5619165e1fa3383d0c2519f502d9e2a1a9
CVE-2021-46918
description
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: clear MSIX permission entry on shutdown Add disabling/clearing of MSIX permission entries on device shutdown to mirror the enabling of the MSIX entries on probe. Current code left the MSIX enabled and the pasid entries still programmed at device shutdown.
description
在Linux内核中,已解决以下漏洞:dmaengine:idxd:clear MSIX permission entry on shutdown添加设备关闭时禁用/清除MSIX权限项,以镜像启用探测时的MSIX项。当前代码使MSIX处于启用状态,并且在设备关闭时仍对pasid条目进行编程。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://git.kernel.org/stable/c/6df0e6c57dfc064af330071f372f11aa8c584997
- https://git.kernel.org/stable/c/c84b8982d7aa9b4717dc36a1c6cbc93ee153b500
CVE-2021-46919
description
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix wq size store permission state WQ size can only be changed when the device is disabled. Current code allows change when device is enabled but wq is disabled. Change the check to detect device state.
description
在Linux内核中,已解决以下漏洞:dmaengine:idxd:fix wq大小存储权限状态wq大小只能在设备禁用时更改。当前代码允许在启用设备但禁用wq时进行更改。更改检查以检测设备状态。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/05b7791c4c4aa8304368fdc55ae911f6b34e7281
- https://git.kernel.org/stable/c/0fff71c5a311e1264988179f7dcc217fda15fadd
- https://git.kernel.org/stable/c/4ecf25595273203010bc8318c4aee60ad64037ae
CVE-2021-46920
description
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix clobbering of SWERR overflow bit on writeback Current code blindly writes over the SWERR and the OVERFLOW bits. Write back the bits actually read instead so the driver avoids clobbering the OVERFLOW bit that comes after the register is read.
description
在Linux内核中,已解决以下漏洞:dmaengine:idxd:修复写回时SWERR溢出位的阻塞当前代码盲目写入SWERR和overflow位。相反,写回实际读取的位,这样驱动器就可以避免对寄存器读取后的OVERFLOW位造成冲击。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/02981a44a0e402089775416371bd2e0c935685f8
- https://git.kernel.org/stable/c/a5ad12d5d69c63af289a37f05187a0c6fe93553d
- https://git.kernel.org/stable/c/ea941ac294d75d0ace50797aebf0056f6f8f7a7f
CVE-2021-46921
description
In the Linux kernel, the following vulnerability has been resolved: locking/qrwlock: Fix ordering in queued_write_lock_slowpath() While this code is executed with the wait_lock held, a reader can acquire the lock without holding wait_lock. The writer side loops checking the value with the atomic_cond_read_acquire(), but only truly acquires the lock when the compare-and-exchange is completed successfully which isn’t ordered. This exposes the window between the acquire and the cmpxchg to an A-B-A problem which allows reads following the lock acquisition to observe values speculatively before the write lock is truly acquired. Weve seen a problem in epoll where the reader does a xchg while holding the read lock, but the writer can see a value change out from under it. Writer | Reader ——————————————————————————– ep_scan_ready_list() | |- write_lock_irq() | |- queued_write_lock_slowpath() | |- atomic_cond_read_acquire() | | read_lock_irqsave(&ep->lock, flags); –> (observes value before unlock) | chain_epi_lockless() | | epi->next = xchg(&ep->ovflist, epi); | | read_unlock_irqrestore(&ep->lock, flags); | | | atomic_cmpxchg_relaxed() | |– READ_ONCE(ep->ovflist); | A core can order the read of the ovflist ahead of the atomic_cmpxchg_relaxed(). Switching the cmpxchg to use acquire semantics addresses this issue at which point the atomic_cond_read can be switched to use relaxed semantics. [peterz: use try_cmpxchg()]
description
在Linux内核中,已解决以下漏洞:locking/qrwlock:修复queued_write_lock_slowpath()中的排序问题。当在持有wait_lock的情况下执行此代码时,读取器可以在不持有wait_ock的情况下获取锁。编写器端使用atomic_cond_read_acquire()循环检查值,但只有当比较和交换成功完成时才真正获取锁,这不是;t已订购。这将获取和cmpxchg之间的窗口暴露为A-B-A问题,这允许在锁获取之后的读取在真正获取写锁之前推测性地观察值。我们在epoll中看到了一个问题,读卡器在持有读锁的同时执行xchg,但写入器可以看到它下面的值发生了变化。写入器|读卡器————————————————————————————ep_scan_ready_list()||-write_lock_irq()|-queued_write_lock_slowpath()|-atomic_cond_read_acquire()|read_lock_ir qsave(&ep->lock,flags);–>(解锁前观察值)|chain_epi_lockless()||epi->next=xchg(&ep->ovflist,epi);||read_unlock_irqrestore(&ep->lock,flags);|||atomic_cmpxchg_relaxed()||–READ_ONCE(ep->ovflist);|核心可以在atomic_cmpxchg_relaxed()之前顺序读取ovflist。将cmpxchg切换为使用获取语义解决了这个问题,此时atomic_cond_read可以切换为使用宽松语义。[peterz:使用try_cmpxchg()]
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/5902f9453a313be8fe78cbd7e7ca9dba9319fc6e
- https://git.kernel.org/stable/c/82808cc026811fbc3ecf0c0b267a12a339eead56
- https://git.kernel.org/stable/c/82fa9ced35d88581cffa4a1c856fc41fca96d80a
- https://git.kernel.org/stable/c/84a24bf8c52e66b7ac89ada5e3cfbe72d65c1896
- https://git.kernel.org/stable/c/d558fcdb17139728347bccc60a16af3e639649d2
CVE-2021-46922
description
In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix TPM reservation for seal/unseal The original patch 8c657a0590de (“KEYS: trusted: Reserve TPM for seal and unseal operations”) was correct on the mailing list: https://lore.kernel.org/linux-integrity/20210128235621.127925-4-jarkko@kernel.org/ But somehow got rebased so that the tpm_try_get_ops() in tpm2_seal_trusted() got lost. This causes an imbalanced put of the TPM ops and causes oopses on TIS based hardware. This fix puts back the lost tpm_try_get_ops()
description
在Linux内核中,已解决以下漏洞:KEYS:trusted:修复密封/解封的TPM保留邮件列表上的原始补丁8c657a0590de(“KEYS:trused:为密封和解封操作保留TPM”)是正确的:https://lore.kernel.org/linux-integrity/20210128235621.127925-4-jarkko@kernel.org/但不知何故被重新设置了基础,因此tpm2_seal_trusted()中的tpm_try_get_ops()丢失了。这会导致TPM操作的不平衡,并导致基于TIS的硬件出现漏洞。此修复程序恢复丢失的tpm_try_get_ops()
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://git.kernel.org/stable/c/39c8d760d44cb3fa0d67e8cd505df81cf4d80999
- https://git.kernel.org/stable/c/bf84ef2dd2ccdcd8f2658476d34b51455f970ce4
CVE-2021-46923
description
In the Linux kernel, the following vulnerability has been resolved: fs/mount_setattr: always cleanup mount_kattr Make sure that finish_mount_kattr() is called after mount_kattr was succesfully built in both the success and failure case to prevent leaking any references we took when we built it. We returned early if path lookup failed thereby risking to leak an additional reference we took when building mount_kattr when an idmapped mount was requested.
description
在Linux内核中,以下漏洞已得到解决:fs/mount_setattr:always-cleanup mount_kattr确保在成功和失败的情况下成功构建mount_kattr后调用finish_mount_kattr(),以防止在构建它时泄露任何引用。如果路径查找失败,我们会提前返回,从而有可能泄露我们在请求idmapped装载时构建mount_kattr时获取的额外引用。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://git.kernel.org/stable/c/012e332286e2bb9f6ac77d195f17e74b2963d663
- https://git.kernel.org/stable/c/47b5d0a7532d39e42a938f81e3904268145c341d
CVE-2021-46924
description
In the Linux kernel, the following vulnerability has been resolved: NFC: st21nfca: Fix memory leak in device probe and remove phy->pending_skb is alloced when device probe, but forgot to free in the error handling path and remove path, this cause memory leak as follows: unreferenced object 0xffff88800bc06800 (size 512): comm “8”, pid 11775, jiffies 4295159829 (age 9.032s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace: [<00000000d66c09ce>] __kmalloc_node_track_caller+0x1ed/0x450 [<00000000c93382b3>] kmalloc_reserve+0x37/0xd0 [<000000005fea522c>] __alloc_skb+0x124/0x380 [<0000000019f29f9a>] st21nfca_hci_i2c_probe+0x170/0x8f2 Fix it by freeing pending_skb in error and remove.
description
在Linux内核中,已解决以下漏洞:NFC:st21nfca:修复设备探测中的内存泄漏,并删除设备探测时分配的phy->pending_skb,但忘记释放错误处理路径和删除路径,这导致内存泄漏如下:未引用的对象0xffffff88800bc06800(大小512):comm“8”,pid 11775,jiffies 4295159829(年龄9.032s)十六进制转储(前32字节): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. 回溯:[<00000000d66c09ce>]__kmalloc_node_track_caller+0x1ed/0x450[<00000000c93382b3>]kmalloc_serve+0x37/0xd0[<000000005fea522c>]__alloc_skb+0x124/0x380[<0000000019f29f9a>]st21nfca_hci_i2c_probe+0x170/0x8f2通过释放错误的pending_skb来修复并删除它。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 8.10% |
references
- https://git.kernel.org/stable/c/1b9dadba502234eea7244879b8d5d126bfaf9f0c
- https://git.kernel.org/stable/c/1cd4063dbc91cf7965d73a6a3855e2028cd4613b
- https://git.kernel.org/stable/c/238920381b8925d070d32d73cd9ce52ab29896fe
- https://git.kernel.org/stable/c/38c3e320e7ff46f2dc67bc5045333e63d9f8918d
- https://git.kernel.org/stable/c/a1e0080a35a16ce3808f7040fe0c3a8fdb052349
- https://git.kernel.org/stable/c/e553265ea56482da5700f56319fda9ff53e7dcb4
CVE-2021-46925
description
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix kernel panic caused by race of smc_sock A crash occurs when smc_cdc_tx_handler() tries to access smc_sock but smc_release() has already freed it. [ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88 [ 4570.696048] #PF: supervisor write access in kernel mode [ 4570.696728] #PF: error_code(0x0002) - not-present page [ 4570.697401] PGD 0 P4D 0 [ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111 [ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0 [ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30 <…> [ 4570.711446] Call Trace: [ 4570.711746] [ 4570.711992] smc_cdc_tx_handler+0x41/0xc0 [ 4570.712470] smc_wr_tx_tasklet_fn+0x213/0x560 [ 4570.712981] ? smc_cdc_tx_dismisser+0x10/0x10 [ 4570.713489] tasklet_action_common.isra.17+0x66/0x140 [ 4570.714083] __do_softirq+0x123/0x2f4 [ 4570.714521] irq_exit_rcu+0xc4/0xf0 [ 4570.714934] common_interrupt+0xba/0xe0 Though smc_cdc_tx_handler() checked the existence of smc connection, smc_release() may have already dismissed and released the smc socket before smc_cdc_tx_handler() further visits it. smc_cdc_tx_handler() |smc_release() if (!conn) | | |smc_cdc_tx_dismiss_slots() | smc_cdc_tx_dismisser() | |sock_put(&smc->sk) <- last sock_put, | smc_sock freed bh_lock_sock(&smc->sk) (panic) | To make sure we wont receive any CDC messages after we free the smc_sock, add a refcount on the smc_connection for inflight CDC message(posted to the QP but havent received related CQE), and dont release the smc_connection until all the inflight CDC messages haven been done, for both success or failed ones. Using refcount on CDC messages brings another problem: when the link is going to be destroyed, smcr_link_clear() will reset the QP, which then remove all the pending CQEs related to the QP in the CQ. To make sure all the CQEs will always come back so the refcount on the smc_connection can always reach 0, smc_ib_modify_qp_reset() was replaced by smc_ib_modify_qp_error(). And remove the timeout in smc_wr_tx_wait_no_pending_sends() since we need to wait for all pending WQEs done, or we may encounter use-after- free when handling CQEs. For IB device removal routine, we need to wait for all the QPs on that device been destroyed before we can destroy CQs on the device, or the refcount on smc_connection wont reach 0 and smc_sock cannot be released.
description
在Linux内核中,已解决以下漏洞:net/smc:修复由smc_sock争用引起的内核死机当smc_cdc_tx_handler()尝试访问smc_socck但smc_release()已释放它时,会发生崩溃。[4570。695099]BUG:无法处理地址为00000000 2eae9e88[4570。696048]#PF:内核模式下的主管写入访问[4570。6916728]#PF:error_code(0x0002)-不存在页面[4570。697401]PGD 0 P4D 0[4570。T SMP NOPTI【4570.698228】CPU:0 PID:0 Comm:swapper/0未污染5.16.0-rc4+#111【4570.692013】硬件名称:阿里云阿里云ECS,BIOS 8c24b4c 04/0【4570.699233】RIP:0010:_raw_spin_lock+0x1a/0x30<…>[4570.711446]调用跟踪:[4570.711746][4570.711992]smc_cdc_tx_handler+0x41/0xc0[4570.712470]smc_wr_tx_tasklet_fn+0x213/0x560[4570.712981]?smc_cdc_tx_dismisser+0x10/0x10[4570.713489]tasklet_action_common.isra.17+0x66/0x140[4570.714083]__do_softirq+0x123/0x2f4[4570.714521]irq_exit_rcu+0xc4/0xf0[4570.714934]common_interrupt+0xfa/0xe0尽管smc_cdc_tx_handler()检查了smc连接的存在,但smc_release()可能在smc_cdc.tx_handle()进一步访问之前已经解除并释放了smc套接字。c_tx_handler()|smc_release()if(!conn)||smc_cdc_tx_dismiss_slots既有成功的,也有失败的。在CDC消息上使用refcount带来了另一个问题:当链路将被破坏时,smcr_link_clear()将重置QP,然后删除CQ中与QP相关的所有挂起的CQE。为了确保所有CQE始终返回,以便smc_connection上的refcount始终可以达到0,smc_ib_modify_QP_reset()被smc_ib_modify_q_error()取代。并删除smc_wr_tx_wait_no_pending_sends()中的超时,因为我们需要等待所有挂起的WQE完成,否则在处理CQE时可能会遇到使用after-free。对于IB设备移除例程,我们需要等待该设备上的所有QP都被销毁,然后才能销毁设备上的CQ,否则smc_connection上的refcount将不会达到0,并且smc_sock无法释放。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/349d43127dac00c15231e8ffbcaabd70f7b0e544
- https://git.kernel.org/stable/c/b85f751d71ae8e2a15e9bda98852ea9af35282eb
- https://git.kernel.org/stable/c/e8a5988a85c719ce7205cb00dcf0716dcf611332
CVE-2021-46926
description
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: intel-sdw-acpi: harden detection of controller The existing code currently sets a pointer to an ACPI handle before checking that its actually a SoundWire controller. This can lead to issues where the graph walk continues and eventually fails, but the pointer was set already. This patch changes the logic so that the information provided to the caller is set when a controller is found.
description
在Linux内核中,已解决以下漏洞:ALSA:hda:intel-sdw-acpi:harden detection of controller现有代码在检查acpi句柄是否为SoundWire控制器之前,当前将指针设置为acpi句柄。这可能会导致图遍历继续并最终失败的问题,但指针已经设置好了。此修补程序更改逻辑,以便在找到控制器时设置提供给调用方的信息。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://git.kernel.org/stable/c/385f287f9853da402d94278e59f594501c1d1dad
- https://git.kernel.org/stable/c/cce476954401e3421afafb25bbaa926050688b1d
CVE-2021-46927
description
In the Linux kernel, the following vulnerability has been resolved: nitro_enclaves: Use get_user_pages_unlocked() call to handle mmap assert After commit 5b78ed24e8ec (“mm/pagemap: add mmap_assert_locked() annotations to find_vma*()”), the call to get_user_pages() will trigger the mmap assert. static inline void mmap_assert_locked(struct mm_struct *mm) { lockdep_assert_held(&mm->mmap_lock); VM_BUG_ON_MM(!rwsem_is_locked(&mm->mmap_lock), mm); } [ 62.521410] kernel BUG at include/linux/mmap_lock.h:156! ………………………………………………….. [ 62.538938] RIP: 0010:find_vma+0x32/0x80 ………………………………………………….. [ 62.605889] Call Trace: [ 62.608502] [ 62.610956] ? lock_timer_base+0x61/0x80 [ 62.614106] find_extend_vma+0x19/0x80 [ 62.617195] __get_user_pages+0x9b/0x6a0 [ 62.620356] __gup_longterm_locked+0x42d/0x450 [ 62.623721] ? finish_wait+0x41/0x80 [ 62.626748] ? __kmalloc+0x178/0x2f0 [ 62.629768] ne_set_user_memory_region_ioctl.isra.0+0x225/0x6a0 [nitro_enclaves] [ 62.635776] ne_enclave_ioctl+0x1cf/0x6d7 [nitro_enclaves] [ 62.639541] __x64_sys_ioctl+0x82/0xb0 [ 62.642620] do_syscall_64+0x3b/0x90 [ 62.645642] entry_SYSCALL_64_after_hwframe+0x44/0xae Use get_user_pages_unlocked() when setting the enclave memory regions. Thats a similar pattern as mmap_read_lock() used together with get_user_pages().
description
在Linux内核中,已解决以下漏洞:nitro_enclaves:使用get_user_pages_unlocked()调用处理mmap assert在提交5b78ed24e8ec(“mm/pagemap:add mmap_assert_locked(()annotations to find_vma*()”)之后,对get_user/pages()的调用将触发mmap assert。静态内联void mmap_assert_locked(struct mm_struct*mm){lockdep_assert_holded(&mm->mmap_lock);VM_BUG_ON_mm(!rwsem_is_locked(&mm->mmap_locked),mm);}[66.221410]内核BUG at include/linux/mmap_lock.h:156。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。[62.538938]RIP:0010:find_vma+0x32/0x80。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。[62.605889]调用跟踪:[62.608502]<TASK>[62.610556]?lock_timer_base+0x61/0x80[6.2614106]find_extend_vma+0x19/0x80[62.617195]__get_user_pages+0x9b/0x6a0[62.620356]__gup_longterm_locked+0x42d/0x450[62.632721]?finish_wait+0x41/0x80[62.626748]__kmalloc+0x178/0x2f0[62.629768]ne_set_user_memory_regon_octl.isra:0+0x225/0x6a0[硝基术语][62.635776]ne_enclave_ioctl+0x1cf/0x6d7[硝基术语][62.639541]__x64_sys_ioctl+0x82/0xb0[62.64220]do_syscall_64+0x3b/0x90[62.654642]entry_syscall_64_after_hwframe+0x44/0xae设置飞地内存区域时使用get_user_pages_unlocked()。这与mmap_read_lock()与get_user_pages()一起使用的模式类似。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://git.kernel.org/stable/c/3a0152b219523227c2a62a0a122cf99608287176
- https://git.kernel.org/stable/c/90d2beed5e753805c5eab656b8d48257638fe543
CVE-2021-46928
description
In the Linux kernel, the following vulnerability has been resolved: parisc: Clear stale IIR value on instruction access rights trap When a trap 7 (Instruction access rights) occurs, this means the CPU couldnt execute an instruction due to missing execute permissions on the memory region. In this case it seems the CPU didnt even fetched the instruction from memory and thus did not store it in the cr19 (IIR) register before calling the trap handler. So, the trap handler will find some random old stale value in cr19. This patch simply overwrites the stale IIR value with a constant magic “bad food” value (0xbaadf00d), in the hope people dont start to try to understand the various random IIR values in trap 7 dumps.
description
在Linux内核中,已解决以下漏洞:paric:清除指令访问权限陷阱上过时的IIR值当出现陷阱7(指令访问权限)时,这意味着CPU由于缺少对内存区域的执行权限而无法执行指令。在这种情况下,CPU似乎甚至没有从内存中提取指令,因此在调用陷阱处理程序之前没有将其存储在cr19(IIR)寄存器中。因此,陷阱处理程序将在cr19中找到一些随机的陈旧值。这个补丁只是用一个不变的魔法“坏食物”值(0xbaadf00d)覆盖陈旧的IIR值,希望人们不要开始试图理解陷阱7转储中的各种随机IIR值。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/484730e5862f6b872dca13840bed40fd7c60fa26
- https://git.kernel.org/stable/c/d01e9ce1af6116f812491d3d3873d204f10ae0b8
- https://git.kernel.org/stable/c/e96373f0a5f484bc1e193f9951dcb3adf24bf3f7
CVE-2021-46929
description
In the Linux kernel, the following vulnerability has been resolved: sctp: use call_rcu to free endpoint This patch is to delay the endpoint free by calling call_rcu() to fix another use-after-free issue in sctp_sock_dump(): BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20 Call Trace: __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline] _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 spin_lock_bh include/linux/spinlock.h:334 [inline] __lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/0x120 net/core/sock.c:2774 lock_sock include/net/sock.h:1492 [inline] sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324 sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091 sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527 __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065 netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:216 [inline] inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cmd net/core/sock_diag.c:232 [inline] sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274 This issue occurs when asoc is peeled off and the old sk is freed after getting it by asoc->base.sk and before calling lock_sock(sk). To prevent the sk free, as a holder of the sk, ep should be alive when calling lock_sock(). This patch uses call_rcu() and moves sock_put and ep free into sctp_endpoint_destroy_rcu(), so that its safe to try to hold the ep under rcu_read_lock in sctp_transport_traverse_process(). If sctp_endpoint_hold() returns true, it means this ep is still alive and we have held it and can continue to dump it; If it returns false, it means this ep is dead and can be freed after rcu_read_unlock, and we should skip it. In sctp_sock_dump(), after locking the sk, if this ep is different from tsp->asoc->ep, it means during this dumping, this asoc was peeled off before calling lock_sock(), and the sk should be skipped; If this ep is the same with tsp->asoc->ep, it means no peeloff happens on this asoc, and due to lock_sock, no peeloff will happen either until release_sock. Note that delaying endpoint free wont delay the port release, as the port release happens in sctp_endpoint_destroy() before calling call_rcu(). Also, freeing endpoint by call_rcu() makes it safe to access the sk by asoc->base.sk in sctp_assocs_seq_show() and sctp_rcv(). Thanks Jones to bring this issue up. v1->v2: - improve the changelog. - add kfree(ep) into sctp_endpoint_destroy_rcu(), as Jakub noticed.
description
在Linux内核中,已解决以下漏洞:sctp:use call_rcu to free endpoint此修补程序通过调用call_rcu()修复sctp_sock_dump()中的另一个释放后使用问题来延迟端点释放:BUG:KASAN:在__lock_acquire+0x36d9/0x4c20调用跟踪中释放后使用:__lock_aaquire+00x6d9/0x4c20内核/锁定/锁定dep.c:3218 lock_acqquire+0x1ed/0x520内核/锁止/锁定dep c:384__raw_spin_lock_bh include/linux/spinlock_api_smp.h:135[inline]_raw_spin_llock_bh+0x31/0x40内核/锁定/spinlock.c:168 spin_lock_bhinclude/linux/spinlock.h:334[inline]__lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/0x120 net/core/stock.c:2774 lock_sock-include/net/sock.h:1492[inline]sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324 sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:591 sctp_diag_dump+0x3ac/0x660 net/sctt/diag.c:527 __inet_diag_dmp+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag-dump+0x9b/0x110 net/ipv4/inet_diag.c:1065 netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352 netlink_damp_startinclude/linux/netlink.h:216[inline]inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cmd net/core/sock_diag.c:232[inline]sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:22477 sock_dag_rcv+0x2a/0x40 net/core/stock_diag.c:274当asoc被剥离,并且旧的sk在通过asoc->base.sk获取后释放,并且在调用lock_sock(sk)之前释放时,就会出现此问题。为了防止sk空闲,作为sk的持有者,ep在调用lock_sock()时应该是活动的。此修补程序使用call_rcu()并将sock_put和ep free移动到sctp_endpoint_destroy_rc()中,因此尝试将ep保持在sctp_transport_traverse_process()中的rcu_read_lock下是安全的。如果sctp_endpoint_hold()返回true,则表示该ep仍然有效,并且我们已经持有它,可以继续转储它;如果返回false,则表示这个ep已经死了,可以在rcu_read_unlock之后释放,我们应该跳过它。在sctp_sock_dump()中,锁定sk之后,如果这个ep与tsp->asoc->ep不同,则表示在这个转储过程中,这个asoc在调用lock_sock()之前被剥离,应该跳过sk;如果此ep与tsp->asoc->ep相同,则意味着此asoc上不会发生剥离,并且由于lock_sock,在release_sock之前也不会发生剥离。请注意,延迟端点释放不会延迟端口释放,因为端口释放发生在调用call_rcu()之前的sctp_endpoint_destroy()中。此外,通过call_rcu()释放端点可以安全地通过sctp_assocs_seq_show()和sctp_rcv()中的asoc->base.sk访问sk。感谢Jones提出这个问题。v1->v2:-改进变更日志。-将kfree(ep)添加到sctp_endpoint_destroy_rc()中,正如Jakub所注意到的。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 8.10% |
references
- https://git.kernel.org/stable/c/5ec7d18d1813a5bead0b495045606c93873aecbb
- https://git.kernel.org/stable/c/75799e71df1da11394740b43ae5686646179561d
- https://git.kernel.org/stable/c/769d14abd35e0e153b5149c3e1e989a9d719e3ff
- https://git.kernel.org/stable/c/831de271452b87657fcf8d715ee20519b79caef5
- https://git.kernel.org/stable/c/8873140f95d4977bf37e4cf0d5c5e3f6e34cdd3e
- https://git.kernel.org/stable/c/af6e6e58f7ebf86b4e7201694b1e4f3a62cbc3ec
CVE-2021-46930
description
In the Linux kernel, the following vulnerability has been resolved: usb: mtu3: fix list_head check warning This is caused by uninitialization of list_head. BUG: KASAN: use-after-free in __list_del_entry_valid+0x34/0xe4 Call trace: dump_backtrace+0x0/0x298 show_stack+0x24/0x34 dump_stack+0x130/0x1a8 print_address_description+0x88/0x56c __kasan_report+0x1b8/0x2a0 kasan_report+0x14/0x20 __asan_load8+0x9c/0xa0 __list_del_entry_valid+0x34/0xe4 mtu3_req_complete+0x4c/0x300 [mtu3] mtu3_gadget_stop+0x168/0x448 [mtu3] usb_gadget_unregister_driver+0x204/0x3a0 unregister_gadget_item+0x44/0xa4
description
在Linux内核中,已解决以下漏洞:usb:mtu3:fix list_head check warning这是由未初始化list_head引起的。BUG:KASAN:在__list_del_entry_valid+0x34/0xe4中免费后使用呼叫跟踪:dump_backtrace+0x0/0x298 show_stack+0x24/0x34 dump_stack+0x130/0x1a8 print_addressdescription+0x88/0x56c __KASAN_report+0x1b8/0x2a0 KASAN_report+0x14/0x20 __asan_load8+0x9c/0xa0 __list_del_entry_valid+0.x34/0xe4 mtu3_req_complete+0x4c/0x300[mtu3]mtu3_gadget_stop+0x168/0x448[mtu3]usb_gadget_unregister_driver+0x204/0x3a0 unregister_gadget_item+0x44/0xa4
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/249ddfbe00570d6dc76208e88017937d4d374c79
- https://git.kernel.org/stable/c/3b6efe0b7ba03cc2acf0694b46d6ff33c5b4c295
- https://git.kernel.org/stable/c/585e2b244dda7ea733274e4b8fa27853d625d3bf
- https://git.kernel.org/stable/c/8c313e3bfd9adae8d5c4ba1cc696dcbc86fbf9bf
CVE-2021-46931
description
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Wrap the tx reporter dump callback to extract the sq Function mlx5e_tx_reporter_dump_sq() casts its void * argument to struct mlx5e_txqsq *, but in TX-timeout-recovery flow the argument is actually of type struct mlx5e_tx_timeout_ctx *. mlx5_core 0000:08:00.1 enp8s0f1: TX timeout detected mlx5_core 0000:08:00.1 enp8s0f1: TX timeout on queue: 1, SQ: 0x11ec, CQ: 0x146d, SQ Cons: 0x0 SQ Prod: 0x1, usecs since last trans: 21565000 BUG: stack guard page was hit at 0000000093f1a2de (stack is 00000000b66ea0dc..000000004d932dae) kernel stack overflow (page fault): 0000 [#1] SMP NOPTI CPU: 5 PID: 95 Comm: kworker/u20:1 Tainted: G W OE 5.13.0_mlnx #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e mlx5e_tx_timeout_work [mlx5_core] RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180 [mlx5_core] Call Trace: mlx5e_tx_reporter_dump+0x43/0x1c0 [mlx5_core] devlink_health_do_dump.part.91+0x71/0xd0 devlink_health_report+0x157/0x1b0 mlx5e_reporter_tx_timeout+0xb9/0xf0 [mlx5_core] ? mlx5e_tx_reporter_err_cqe_recover+0x1d0/0x1d0 [mlx5_core] ? mlx5e_health_queue_dump+0xd0/0xd0 [mlx5_core] ? update_load_avg+0x19b/0x550 ? set_next_entity+0x72/0x80 ? pick_next_task_fair+0x227/0x340 ? finish_task_switch+0xa2/0x280 mlx5e_tx_timeout_work+0x83/0xb0 [mlx5_core] process_one_work+0x1de/0x3a0 worker_thread+0x2d/0x3c0 ? process_one_work+0x3a0/0x3a0 kthread+0x115/0x130 ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x30 –[ end trace 51ccabea504edaff ]— RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180 PKRU: 55555554 Kernel panic - not syncing: Fatal exception Kernel Offset: disabled end Kernel panic - not syncing: Fatal exception To fix this bug add a wrapper for mlx5e_tx_reporter_dump_sq() which extracts the sq from struct mlx5e_tx_timeout_ctx and set it as the TX-timeout-recovery flow dump callback.
description
在Linux内核中,已解决以下漏洞:net/mlx5e:包装tx报告程序转储回调以提取sq函数mlx5e_tx_reporter_dump_sq()将其void参数强制转换为struct mlx5e_txqsq,但在tx超时恢复流中,该参数的类型实际上为struct mlx5e_tx_timeout_ctx*。mlx5_core 0000:08:00.1 enp8s0f1:检测到TX超时mlx5_core0000:08:03.1 enp8 s0f1:队列上的TX超时:1,SQ:0x11ec,CQ:0x146d,SQ Cons:0x0 SQ Prod:0x1,自上次传输以来使用次数:21565000 BUG:堆栈保护页在0000000093f1a2de处命中(堆栈为00000000b66ea0dc.000000004d932dae)内核堆栈溢出(页面错误):0000[#1]SMP NOPTI CPU:5 PID:95 Comm:kworker/u20:1损坏:G W OE 5.13.0 _mlnx#1硬件名称:QEMU标准PC(Q35+ICH92009),BIOS rel-1.13.0-0-gf21b5a4aeb02-rebuild.QEMU.org 2014年1月4日工作队列:mlx5e mlx5e_TX_timeout_work[mlx5_core]RIP:0010:mlx5e_TX_reporter_dump_SQ+0xd3/0x180[mlx5-core]调用跟踪:mlx5e_TX_reporter_dump+0x43/0x1c0[mlx5/core]devlink_health_do_dump.part.91+0x71/0xd0 devlink_hhealth_report+0x157/0x1 b0 mlx5e_reporter_TX_timeout+0xb9/0xf0[mlx5_core]?mlx5e_tx_reporter_err_cqe_recover+0x1d0/0x1d0[mlx5_core]?mlx5e_health_queue_dump+0xd0/0xd0[mlx5_core]?update_load_avg+0x19b/0x550?set_next_entity+0x72/0x80?pick_next_task_fair+0x227/0x340?finish_task_switch+0x22/0x280 mlx5e_tx_timeout_work+0x83/0xb0[mlx5_core]process_one_work+0x1de/0x3a0 worker_thread+0x2d/0x3c0?process_one_work+0x3a0/0x3a0 k线程+0x115/0x130?kthread_park+0x90/0x90 ret_from_fork+0x1f/0x30–[结束跟踪51ccabea504edaff]-RIP:0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180 PKRU:555555555 4内核死机-未同步:致命异常内核偏移:禁用端内核死机-不同步:致命例外要修复此错误,请为mlx5e_tx_reporter_dump_sq()添加一个包装,该包装从结构mlx5e_tx_timeout_ctx中提取sq,并将其设置为tx超时恢复流转储回调。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/07f13d58a8ecc3baf9a488588fb38c5cb0db484f
- https://git.kernel.org/stable/c/73665165b64a8f3c5b3534009a69be55bb744f05
- https://git.kernel.org/stable/c/918fc3855a6507a200e9cf22c20be852c0982687
CVE-2021-46932
description
In the Linux kernel, the following vulnerability has been resolved: Input: appletouch - initialize work before device registration Syzbot has reported warning in __flush_work(). This warning is caused by work->func == NULL, which means missing work initialization. This may happen, since input_dev->close() calls cancel_work_sync(&dev->work), but dev->work initalization happens after input_register_device() call. So this patch moves dev->work initialization before registering input device
description
在Linux内核中,已解决以下漏洞:输入:appletouch-在设备注册之前初始化工作Syzbot已在__flush_work()中报告警告。此警告是由work->func==NULL引起的,这意味着缺少工作初始化。这种情况可能会发生,因为input_dev->close()调用cancel_work_sync(&dv->work),但dev->work初始化会发生_after_input_register_device()调用。因此,此补丁在注册输入设备之前移动dev->work初始化
cvss | epss | percentile |
---|---|---|
None | 0.04% | 10.59% |
references
- https://git.kernel.org/stable/c/292d2ac61fb0d9276a0f7b7ce4f50426f2a1c99f
- https://git.kernel.org/stable/c/975774ea7528b489930b76a77ffc4d5379b95ff2
- https://git.kernel.org/stable/c/9f329d0d6c91142cf0ad08d23c72dd195db2633c
- https://git.kernel.org/stable/c/9f3ccdc3f6ef10084ceb3a47df0961bec6196fd0
- https://git.kernel.org/stable/c/a02e1404e27855089d2b0a0acc4652c2ce65fe46
- https://git.kernel.org/stable/c/d1962f263a176f493400b8f91bfbf2bfedce951e
- https://git.kernel.org/stable/c/d2cb2bf39a6d17ef4bdc0e59c1a35cf5751ad8f4
- https://git.kernel.org/stable/c/e79ff8c68acb1eddf709d3ac84716868f2a91012
CVE-2021-46933
description
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear. ffs_data_clear is indirectly called from both ffs_fs_kill_sb and ffs_ep0_release, so it ends up being called twice when userland closes ep0 and then unmounts f_fs. If userland provided an eventfd along with functions USB descriptors, it ends up calling eventfd_ctx_put as many times, causing a refcount underflow. NULL-ify ffs_eventfd to prevent these extraneous eventfd_ctx_put calls. Also, set epfiles to NULL right after de-allocating it, for readability. For completeness, ffs_data_clear actually ends up being called thrice, the last call being before the whole ffs structure gets freed, so when this specific sequence happens there is a second underflow happening (but not being reported): /sys/kernel/debug/tracing# modprobe usb_f_fs /sys/kernel/debug/tracing# echo ffs_data_clear > set_ftrace_filter /sys/kernel/debug/tracing# echo function > current_tracer /sys/kernel/debug/tracing# echo 1 > tracing_on (setup gadget, run and kill function userland process, teardown gadget) /sys/kernel/debug/tracing# echo 0 > tracing_on /sys/kernel/debug/tracing# cat trace smartcard-openp-436 [000] ….. 1946.208786: ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] ….. 1946.279147: ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] .n… 1946.905512: ffs_data_clear <-ffs_data_put Warning output corresponding to above trace: [ 1946.284139] WARNING: CPU: 0 PID: 431 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c [ 1946.293094] refcount_t: underflow; use-after-free. [ 1946.298164] Modules linked in: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) bcm2835_v4l2(CE) bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E) sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_bcm2835(CE) brcmfmac(E) mc(E) vc4(E) ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E) sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E) regmap_i2c(E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E) libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E) [ 1946.399633] CPU: 0 PID: 431 Comm: smartcard-openp Tainted: G C OE 5.15.0-1-rpi #1 Debian 5.15.3-1 [ 1946.417950] Hardware name: BCM2835 [ 1946.425442] Backtrace: [ 1946.432048] [] (dump_backtrace) from [] (show_stack+0x20/0x24) [ 1946.448226] r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c [ 1946.458412] [] (show_stack) from [] (dump_stack+0x28/0x30) [ 1946.470380] [] (dump_stack) from [] (__warn+0xe8/0x154) [ 1946.482067] r5:c04a948c r4:c0a71dc8 [ 1946.490184] [] (__warn) from [] (warn_slowpath_fmt+0xa0/0xe4) [ 1946.506758] r7:00000009 r6:0000001c r5:c0a71dc8 r4:c0a71e04 [ 1946.517070] [] (warn_slowpath_fmt) from [] (refcount_warn_saturate+0x110/0x15c) [ 1946.535309] r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0 [ 1946.546708] [] (refcount_warn_saturate) from [] (eventfd_ctx_put+0x48/0x74) [ 1946.564476] [] (eventfd_ctx_put) from [] (ffs_data_clear+0xd0/0x118 [usb_f_fs]) [ 1946.582664] r5:c3b84c00 r4:c2695b00 [ 1946.590668] [] (ffs_data_clear [usb_f_fs]) from [] (ffs_data_closed+0x9c/0x150 [usb_f_fs]) [ 1946.609608] r5:bf54d014 r4:c2695b00 [ 1946.617522] [] (ffs_data_closed [usb_f_fs]) from [] (ffs_fs_kill_sb+0x2c/0x30 [usb_f_fs]) [ 1946.636217] r7:c0dfcb —truncated—
description
在Linux内核中,已解决以下漏洞:usb:gadget:f_fs:Clear ffs_data_Clear中的ffs_eventfd。ffs_data_clear是从ffs_fs_kill_sb和ffs_ep0_release间接调用的,因此当userland关闭ep0然后卸载f_fs时,它最终会被调用两次。如果userland提供了一个eventfd和函数USB描述符,那么它最终会多次调用eventfd_ctx_put,导致refcount下溢。将ffs_eventfd设为NULL以防止这些无关的eventfd_ctx_put调用。此外,为了可读性,在取消分配epfiles后立即将其设置为NULL。为了完整起见,ffs_data_clear实际上被调用了三次,最后一次调用是在整个ffs结构被释放之前,所以当这个特定序列发生时,会发生第二次下溢(但没有报告):/sys/kernel/debug/tracing#modprobe usb_f_fs/sys/kernet/debug/tracing#echo ffs_data_clear>set_ftrace_filter/sys/kernel/debug/tracing#echo function>current_tracer/sys/kenne/debug/tracking#echo 1>tracing_on(设置小工具,运行并终止函数userland进程,拆卸小工具)/sys/kenne/debug/tracking#echo 0>tracing_on/sys/kernet/debug/tracing#cat trace smartcard-openp-436[0000] ….. 1946.208786:ffs_data_clear<-ffs_data_closed smartcard-openp-431[0000]。。。。。1946.279147:ffs_data_clear<-ffs_data_closed smartcard-openp-431[0000].n…1946.905512:ffs_data_clear<-ffs_data_put与上述跟踪对应的警告输出:[1946.284139]警告:CPU:0 PID:431在lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c[1946.293094]refcount_t:下溢;免费后使用。[1946.298164]链接在中的模块:usb_f_ncm(E)u_ether(E)usb_f_fs(E)hci_uart(E)btqca(E)btrtl(E E)videobuf2_common(E)videodev(E)cpufreq_dt(E)snd_bcm2835(CE)brcmfmac(E)mc(E)vc4(E)ctr(E)brcmutil(E)snd_soc_core(E)ecdh_generic(E)rfkill(E)ec(E)bcm2835_rng(E)rng_core(E)vchiq(CE)leds_gpio(E)libcomposite(E)fuse(E)configfs(E)ip_tables(E)x_tables(E>](dump_Backtrace)来自[](show_stack+0x20/0x24)[1946.448226]r7:0000000 9 r6:0000001c r5:c04a948c r4:c0a64e2c[1946.458412][](show_stack)来自[](dump_stack+0x28/0x30)[1946.470380][<c 08d9ab8>](转储_堆栈)来自[](__warn+0xe8/0x154)[19464.82067]r5:c04 a948C r4:c 0a71dc8[1946.490184]3418>](__warn)来自[](warn_slowpath_fmt+0xa0/0xe4)[1946.506758]r7:0000000 9 r6:0000001c r5:c0a71dc8 r4:c0a71 e04[1946.51770][](warn_slowpath_fmt)来自[](refcount_warn_saturate+0x110/0x15c)[1946.5535309]r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0[1946.546708][<c 04a937c>](refcount_warn_saturate)来自[<c03]80134>](事件fd_ctx_put+0x48/0x74)[1946.564476][](eventfd_ctx_prut)来自[](ffs_data_clear+0xd0/0x118[usb_f_fs])[19466.582664]r5:c3b84c00 r4:c2695b00[19466.590668][](ffs_data _clear[usb_f _fs])来自[](ff s_data_closed+0x9c/0x150[usb_f3f])[19466.609608]r5:bf54d014 r4:c269b00[1946.617522][]bf547da0>](ffs_fs_kill_sb+0x2c/0x30[usb_f_fs])[1946.636217]r7:c0dfcb-截断—
cvss | epss | percentile |
---|---|---|
None | 0.04% | 10.59% |
references
- https://git.kernel.org/stable/c/1c4ace3e6b8575745c50dca9e76e0021e697d645
- https://git.kernel.org/stable/c/240fc586e83d645912accce081a48aa63a45f6ee
- https://git.kernel.org/stable/c/33f6a0cbb7772146e1c11f38028fffbfed14728b
- https://git.kernel.org/stable/c/52500239e3f2d6fc77b6f58632a9fb98fe74ac09
- https://git.kernel.org/stable/c/b1e0887379422975f237d43d8839b751a6bcf154
- https://git.kernel.org/stable/c/cc8c8028c21b2a3842a1e98e99e55028df275919
- https://git.kernel.org/stable/c/ebef2aa29f370b5096c16020c104e393192ef684
- https://git.kernel.org/stable/c/f976dd7011150244a7ba820f2c331e9fb253befa
CVE-2021-46934
description
In the Linux kernel, the following vulnerability has been resolved: i2c: validate user data in compat ioctl Wrong user data may cause warning in i2c_transfer(), ex: zero msgs. Userspace should not be able to trigger warnings, so this patch adds validation checks for user data in compact ioctl to prevent reported warnings
description
在Linux内核中,已解决以下漏洞:i2c:validate user data In compat ioctl错误的用户数据可能会导致i2c_transfer()中的警告,例如:零消息。用户空间不应该能够触发警告,因此此修补程序在compact ioctl中添加了对用户数据的验证检查,以防止报告警告
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/407c8708fb1bf2d4afc5337ef50635cf540c364b
- https://git.kernel.org/stable/c/8d31cbab4c295d7010ebb729e9d02d0e9cece18f
- https://git.kernel.org/stable/c/9e4a3f47eff476097e0c7faac04d1831fc70237d
- https://git.kernel.org/stable/c/bb436283e25aaf1533ce061605d23a9564447bdf
- https://git.kernel.org/stable/c/f68599581067e8a5a8901ba9eb270b4519690e26
CVE-2021-46935
description
In the Linux kernel, the following vulnerability has been resolved: binder: fix async_free_space accounting for empty parcels In 4.13, commit 74310e06be4d (“android: binder: Move buffer out of area shared with user space”) fixed a kernel structure visibility issue. As part of that patch, sizeof(void *) was used as the buffer size for 0-length data payloads so the driver could detect abusive clients sending 0-length asynchronous transactions to a server by enforcing limits on async_free_size. Unfortunately, on the “free” side, the accounting of async_free_space did not add the sizeof(void *) back. The result was that up to 8-bytes of async_free_space were leaked on every async transaction of 8-bytes or less. These small transactions are uncommon, so this accounting issue has gone undetected for several years. The fix is to use “buffer_size” (the allocated buffer size) instead of “size” (the logical buffer size) when updating the async_free_space during the free operation. These are the same except for this corner case of asynchronous transactions with payloads < 8 bytes.
description
在Linux内核中,已解决以下漏洞:binder:修复async_free_space占空包裹的问题。在4.13中,commit 74310e06e4d(“android:binder:将缓冲区移出与用户空间共享的区域”)修复了内核结构可见性问题。作为该补丁的一部分,sizeof(void*)被用作0长度数据有效负载的缓冲区大小,因此驱动程序可以通过强制限制async_free_size来检测向服务器发送0长度异步事务的滥用客户端。不幸的是,在“免费”方面,async_free_space的核算没有将sizeof(void*)添加回来。结果是,每一个8字节或更少的异步事务都会泄露多达8字节的async_free_space。这些小额交易并不常见,因此这一会计问题已经好几年没有被发现了。修复方法是在空闲操作期间更新async_free_space时,使用“buffer_size”(分配的缓冲区大小)而不是“size”(逻辑缓冲区尺寸)。除了有效负载小于8字节的异步事务的这种情况之外,这些都是相同的。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 8.10% |
references
- https://git.kernel.org/stable/c/103b16a8c51f96d5fe063022869ea906c256e5da
- https://git.kernel.org/stable/c/17691bada6b2f1d5f1c0f6d28cd9d0727023b0ff
- https://git.kernel.org/stable/c/1cb8444f3114f0bb2f6e3bcadcf09aa4a28425d4
- https://git.kernel.org/stable/c/2d2df539d05205fd83c404d5f2dff48d36f9b495
- https://git.kernel.org/stable/c/7c7064402609aeb6fb11be1b4ec10673ff17b593
- https://git.kernel.org/stable/c/cfd0d84ba28c18b531648c9d4a35ecca89ad9901
CVE-2021-46936
description
In the Linux kernel, the following vulnerability has been resolved: net: fix use-after-free in tw_timer_handler A real world panic issue was found as follow in Linux 5.4. BUG: unable to handle page fault for address: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP: 0010:tw_timer_handler+0x20/0x40 Call Trace: call_timer_fn+0x2b/0x120 run_timer_softirq+0x1ef/0x450 __do_softirq+0x10d/0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120 apic_timer_interrupt+0xf/0x20 This issue was also reported since 2017 in the thread [1], unfortunately, the issue was still can be reproduced after fixing DCCP. The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net namespace is destroyed since tcp_sk_ops is registered befrore ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops in the list of pernet_list. There will be a use-after-free on net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net if there are some inflight time-wait timers. This bug is not introduced by commit f2bf415cfed7 (“mib: add net to NET_ADD_STATS_BH”) since the net_statistics is a global variable instead of dynamic allocation and freeing. Actually, commit 61a7e26028b9 (“mib: put net statistics on struct net”) introduces the bug since it put net statistics on struct net and free it when net namespace is destroyed. Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug and replace pr_crit() with panic() since continuing is meaningless when init_ipv4_mibs() fails. [1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1
description
在Linux内核中,以下漏洞已得到解决:net:fix在tw_timer_handler中修复释放后使用问题在Linux 5.4中发现了一个真实世界的恐慌问题,如下所示。BUG:无法处理地址的页面故障:ffffde49a863de28 PGD 7e6fe62067 P4D 7e5fe62067 PUD 7e6 fe63067 PMD f51e0640667 PTE 0 RIP:0010:tw_timer_handler+0x20/0x40调用跟踪:Call_timer_fn+0x2b/0x120 run_timer_softirq+0x1ef/0x450 __do_softirq+0x10d/0x2b8 IRQ_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120 apic_timeer_interrupt+0.xf/0x20自2017年以来,该问题也在线程[1],不幸的是,该问题在修复DCCP后仍然可以再现。当网络命名空间被破坏时,ipv4_mib_exit_net在tcp_sk_exit_batch之前被调用,因为tcp_sk_ops是在ipv4_mib _ops之前注册的,这意味着tcp_sk _ops在pernet_list的列表中位于ipv4_mib _ops的前面。如果有一些机上时间等待计时器,则在ipv4_mib_exit_net之后的tw_timer_handler中会使用after-free-on->mib.net_statistics。提交f2bf415cfed7(“mib:add net to net_add_STATS_BH”)不会引入此错误,因为net_statistics是一个全局变量,而不是动态分配和释放。事实上,commit 61a7e26028b9(“mib:put net statistics on struct net”)引入了这个错误,因为它将网络统计信息放在struct net上,并在网络命名空间被破坏时释放它。将init_ipv4_mibs()移到tcp_int()的前面以修复此错误,并用panic()替换pr_crit(),因为当init_ipv_4_mibs()失败时,继续操作毫无意义。1.https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1
cvss | epss | percentile |
---|---|---|
None | 0.04% | 10.59% |
references
- https://git.kernel.org/stable/c/08eacbd141e2495d2fcdde84358a06c4f95cbb13
- https://git.kernel.org/stable/c/15579e1301f856ad9385d720c9267c11032a5022
- https://git.kernel.org/stable/c/2386e81a1d277f540e1285565c9d41d531bb69d4
- https://git.kernel.org/stable/c/5c2fe20ad37ff56070ae0acb34152333976929b4
- https://git.kernel.org/stable/c/a8e1944b44f94f5c5f530e434c5eaee787254566
- https://git.kernel.org/stable/c/e22e45fc9e41bf9fcc1e92cfb78eb92786728ef0
- https://git.kernel.org/stable/c/e73164e89d1be561228a4534e1091369ee4ba41a
- https://git.kernel.org/stable/c/fe5838c22b986c1190f1dce9aa09bf6a491c1a69
CVE-2021-46937
description
In the Linux kernel, the following vulnerability has been resolved: mm/damon/dbgfs: fix struct pid leaks in dbgfs_target_ids_write() DAMON debugfs interface increases the reference counts of struct pids for targets from the target_ids file write callback (dbgfs_target_ids_write()), but decreases the counts only in DAMON monitoring termination callback (dbgfs_before_terminate()). Therefore, when target_ids file is repeatedly written without DAMON monitoring start/termination, the reference count is not decreased and therefore memory for the struct pid cannot be freed. This commit fixes this issue by decreasing the reference counts when target_ids is written.
description
在Linux内核中,已解决以下漏洞:mm/damon/dbgfs:修复dbgfs_target_ids_write()中的结构pid泄漏。damon-debugfs接口增加了target_ids文件写入回调(dbgfs_target _ids_writee())中目标的结构pid引用计数,但仅在damon监视终止回调(dbgfs_before_terminate()中减少了计数。因此,当在没有DAMON监视启动/终止的情况下重复写入target_ids文件时,引用计数不会减少,因此无法释放结构pid的内存。此提交通过在写入target_ids时减少引用计数来解决此问题。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://git.kernel.org/stable/c/ebb3f994dd92f8fb4d70c7541091216c1e10cb71
- https://git.kernel.org/stable/c/ffe4a1ba1a82c416a6b3a09d46594f6a885ae141
CVE-2021-46938
description
In the Linux kernel, the following vulnerability has been resolved: dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails When loading a device-mapper table for a request-based mapped device, and the allocation/initialization of the blk_mq_tag_set for the device fails, a following device remove will cause a double free. E.g. (dmesg): device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device device-mapper: ioctl: unable to set up device queue for new table. Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0305e098835de000 TEID: 0305e098835de803 Fault in home space mode while using kernel ASCE. AS:000000025efe0007 R3:0000000000000024 Oops: 0038 ilc:3 [#1] SMP Modules linked in: … lots of modules … Supported: Yes, External CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3 Hardware name: IBM 8561 T01 7I2 (LPAR) Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000 000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640 00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8 Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58 #000000025e368ec4: e3b010000008 ag %r11,0(%r1) >000000025e368eca: e310b0080004 lg %r1,8(%r11) 000000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4: a7740129 brc 7,25e369126 000000025e368ed8: e320b0080004 lg %r2,8(%r11) 000000025e368ede: b904001b lgr %r1,%r11 Call Trace: [<000000025e368eca>] kfree+0x42/0x330 [<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8 [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod] [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod] [<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod] [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod] [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod] [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40 [<000000025e8c15ac>] system_call+0xd8/0x2c8 Last Breaking-Event-Address: [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8 Kernel panic - not syncing: Fatal exception: panic_on_oops When allocation/initialization of the blk_mq_tag_set fails in dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer is not reset to NULL; so when dev_remove() later gets into dm_mq_cleanup_mapped_device() it sees the pointer and tries to uninitialize and free it again. Fix this by setting the pointer to NULL in dm_mq_init_request_queue() error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device().
description
在Linux内核中,已解决以下漏洞:dm rq:fix在表加载失败后修复dev remove中blk_mq_tag_set的双重释放。当为基于请求的映射设备加载设备映射器表,并且为该设备分配/初始化blk_mq_tag-set失败时,以下设备删除将导致双重释放。例如(dmesg):设备映射器:核心:无法初始化基于请求的dm mq映射的设备的队列设备映射程序:ioctl:无法为新表设置设备队列。无法处理虚拟内核地址空间中的内核指针取消引用失败地址:0305e098835de000 TEID:0305e09 8835de803使用内核ASCE时在主空间模式中出错。AS:00000000 25efe007 R3:00000000000000024 Oops:0038 ilc:3[#1]SMP模块链接在:。。。很多模块。。。支持:是,外部CPU:0 PID:7348 Comm:multipathd Kdump:loaded Tained:G W X 5.3.18-53-default#1 SLE15-SP3硬件名称:IBM 8561 T01 7I2(LPAR)Krnl PSW:0074e00180000000 0000000 25e368eca(kfree+0x42/0x330)R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS:0000000000000004a 0000000 25efe2230 c1773200d77968d000000000000000 25e52020 70 0000000 25e8d1b40 000000000000000 3 0000000 7aae10000 0000000 25e 5202a2 000000000000000 1 c17732000d77968d 0305e098835de640 0000000 7a8170000 000003f80138650 0000000 25e-5202a2 000003e0396faa8 Krnl代码:0000000 25e368eb8:c4180041e100 lgrl%r1,25eba50b8 0000000 25e268ebe:ecba06b93a55 risbg%r11,%r10,6185,58#0000000 25E368ec4:e3b010000008 ag%r11,0(%r1)>0000000 e368eca:e310b00080004 lg%r1,8(%r11)0000000 25e368ed0:a7110001 tmll%r1,10000000 25E368ed4:a7740129 brc 7,25e369126 0000000 25E3 68ed8:e320b0080004 lg%r2,8blk_mq_free_tag_set+0x72/0xb8[<000003ff801316a8>]dm_mq_cleanup_apped_device+0x38/0x50[dm_mode][<000003 ff80120082>]free_dev+0x52/0xd0[dm_mode][<000003 f801233f0>]__dm_destroy+0x150/0x1d0[d_mod][<000003f8012bb9a>]dev_remove+0x162/0x1c0[dm_Mode][<00000三f8012a988>]ctl_ioctl+0x198/0x478][dm_mod][<000003ff8012ac8a>]dm_ctl_ioctl+0x22/0x38[dm_mode][<0000000 25e3b11ee>]ksys_ioctl+0xbe/0xe0[<000000 25e3b127a>]__s390x_sys_ioctl+0x2a/0x40[<000000 25e8c15ac>]system_call+0xd8/0x2c8上次中断事件地址:[<00000000 25e52029c>]blk_mq_free_tag_set+0x6c/0xb8内核死机-未同步:致命异常:死机n_oops当dm_mq_init_request_queue()中blk_mq_tag_set的分配/初始化失败时,它被取消初始化/释放,但指针不会重置为NULL;因此,当dev_remove()稍后进入dmmqcleanup_apped_device()时,它会看到指针,并尝试取消初始化并再次释放它。通过在dm_mq_init_request_queue()错误处理中将指针设置为NULL来修复此问题。在dm_mq_cleanup_apped_device()中也将其设置为NULL。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 10.59% |
references
- https://git.kernel.org/stable/c/1cb02dc76f4c0a2749a02b26469512d6984252e9
- https://git.kernel.org/stable/c/6086f957416a6e87236c06079fcaba7a3998aeca
- https://git.kernel.org/stable/c/772b9f59657665af3b68d24d12b9d172d31f0dfb
- https://git.kernel.org/stable/c/8ae0185255eaf05bd66f4215c81e99bf01140fd9
- https://git.kernel.org/stable/c/8e947c8f4a5620df77e43c9c75310dc510250166
- https://git.kernel.org/stable/c/a992a283c0b77d0a7c2c348add0e6a21fb1dab67
- https://git.kernel.org/stable/c/b42c0a33dfdd451d9be62dd5de58c39f2750b6e3
- https://git.kernel.org/stable/c/d757bf4c69cda3c3ab7f775dfabbf5a80e2f6f9d
CVE-2021-46939
description
In the Linux kernel, the following vulnerability has been resolved: tracing: Restructure trace_clock_global() to never block It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 With the following RIP: RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200 Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and then trying to take it again: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* lock taken / (something else gets traced by function graph tracer) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { / DEAD LOCK! */ Tracing should never block, as it can lead to strange lockups like the above. Restructure the trace_clock_global() code to instead of simply taking a lock to update the recorded “prev_time” simply use it, as two events happening on two different CPUs that calls this at the same time, really doesnt matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761
description
在Linux内核中,已解决以下漏洞:trace:将trace_clock_global()重新构造为从不阻塞。据报道,修复环形缓冲区递归检测会导致在执行挂起/恢复测试时挂起计算机。以下回溯是从调试该案例中提取的:调用跟踪:Trace_clock_global+0x91/0xa0__rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x2a/0x3f0 Trace_buffer_lock_reserve+0x10/0x50 __Trace_graph_return+0x1f/0x80 Trace_graph _return+0xb7/0xf0?trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0?pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30?ftrace_graph_caller+0xa0/0xa0?trace_clock_global+0x91/0xa0__rb_reserve_next+0x237/0x460?ring_buffer_lock_reserve+0x12a/0x3f0?trace_event_buffer_lock_reserve+0x3c/0x120?trace_event_buffer_preserve+0x6b/0xc0?trace_event_raw_event_device_pm_callback_start+0x125/0x2d0?dpm_run_callback+0x3b/0xc0?pm_ops_is_empty+0x50/0x50?platform_get_irq_byname_optial+0x90/0x90?trace_device_pm_callback_start+0x82/0xd0?dpm_run_callback+0x49/0xc0使用以下RIP:RIP:0010:native_queued_spin_lock_slowpath+0x69/0x200由于递归检测的修复将允许在跟踪时发生单个递归,这导致trace_clock_global()获取旋转锁,然后尝试再次获取:ring_buffer_lock_reserve(){trace_clock_global({/锁被占用/(其他东西被函数图跟踪器跟踪)ring_buffer_lock_reserve(){trace_clock_global(简单地使用它,因为同时调用它的两个不同CPU上发生的两个事件,实际上哪一个先发生并不重要。使用trylock获取用于更新prev_time的锁,如果失败,只需下次重试。如果它没有被拿走,那就意味着其他东西已经在更新它了。Bugzilla:https://bugzilla.kernel.org/show_bug.cgi?id=212761
cvss | epss | percentile |
---|---|---|
None | 0.04% | 10.59% |
references
- https://git.kernel.org/stable/c/1fca00920327be96f3318224f502e4d5460f9545
- https://git.kernel.org/stable/c/2a1bd74b8186d7938bf004f5603f25b84785f63e
- https://git.kernel.org/stable/c/6e2418576228eeb12e7ba82edb8f9500623942ff
- https://git.kernel.org/stable/c/859b47a43f5a0e5b9a92b621dc6ceaad39fb5c8b
- https://git.kernel.org/stable/c/91ca6f6a91f679c8645d7f3307e03ce86ad518c4
- https://git.kernel.org/stable/c/a33614d52e97fc8077eb0b292189ca7d964cc534
- https://git.kernel.org/stable/c/aafe104aa9096827a429bc1358f8260ee565b7cc
- https://git.kernel.org/stable/c/c64da3294a7d59a4bf6874c664c13be892f15f44
- https://git.kernel.org/stable/c/d43d56dbf452ccecc1ec735cd4b6840118005d7c
CVE-2021-46940
description
In the Linux kernel, the following vulnerability has been resolved: tools/power turbostat: Fix offset overflow issue in index converting The idx_to_offset() function returns type int (32-bit signed), but MSR_PKG_ENERGY_STAT is u32 and would be interpreted as a negative number. The end result is that it hits the if (offset < 0) check in update_msr_sum() which prevents the timer callback from updating the stat in the background when long durations are used. The similar issue exists in offset_to_idx() and update_msr_sum(). Fix this issue by converting the int to off_t accordingly.
description
在Linux内核中,已解决以下漏洞:tools/power-turbostat:修复索引转换中的偏移溢出问题idx_to_offset()函数返回类型int(32位有符号),但MSR_PKG_ENERGY_STAT是u32,将被解释为负数。最终结果是,它在update_msr_sum()中命中了if(offset<0)检查,这会阻止计时器回调在使用长持续时间时在后台更新stat。offset_to_idx()和update_msr_sum()中也存在类似的问题。通过相应地将int转换为off_t来解决此问题。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/13a779de4175df602366d129e41782ad7168cef0
- https://git.kernel.org/stable/c/337b1546cde87fb8588ddaedf0201b769baa572a
- https://git.kernel.org/stable/c/dbdf22fc825fdb1d97f23230064e0f9819471628
- https://git.kernel.org/stable/c/ea6803ff2cd1a2d7d880256bf562172b708a76ff
CVE-2021-46941
description
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: Do core softreset when switch mode According to the programming guide, to switch mode for DRD controller, the driver needs to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence Currently were missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferrys testing platform[2]. So, apply the required steps along with some fixes to Yu Chens and John Stultzs version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/
description
在Linux内核中,以下漏洞已被解决:usb:dwc3:core:切换模式时执行核心软重置根据编程指南,要切换DRD控制器的模式,驱动程序需要执行以下操作。要从设备切换到主机,请执行以下操作:1。使用GCTL重置控制器。CoreSoftReset 2。设置GCTL。PrtCapDir(主机模式)3。使用USBCMD重置主机。HCRESET 4。然后按照初始化主机寄存器序列从主机切换到设备:1。使用GCTL重置控制器。CoreSoftReset 2。设置GCTL。PrtCapDir(设备模式)3。使用DCTL重置设备。CSftRst 4。然后按照初始化寄存器的顺序进行后续操作。当前缺少步骤1)来执行GCTL。CoreSoftReset和从主机切换到设备的步骤3)。John Stult报告称,在没有这些步骤的情况下,HiKey960平台出现锁定问题[1]。Ferrys测试平台也存在类似问题[2]。因此,将所需的步骤以及一些修复程序应用于Yu Chens和John Stultzs版本。对其版本的主要修复是在清除GCTL之前缺少对时钟同步的等待。CoreSoftReset并仅应用DCTL。从主机切换到设备时的CSftRst。1.https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/[2]https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/1c10fd60c8595ea7ff7e29d3cf1fa88069941da3
- https://git.kernel.org/stable/c/800f58217626c8b147aa40660e572ed8a0d56e3b
- https://git.kernel.org/stable/c/f88359e1588b85cf0e8209ab7d6620085f3441d9
- https://git.kernel.org/stable/c/fce7bbcd07d59ac30dba8ce225316b3b4c1c7b50
CVE-2021-46942
description
In the Linux kernel, the following vulnerability has been resolved: io_uring: fix shared sqpoll cancellation hangs [ 736.982891] INFO: task iou-sqp-4294:4295 blocked for more than 122 seconds. [ 736.982897] Call Trace: [ 736.982901] schedule+0x68/0xe0 [ 736.982903] io_uring_cancel_sqpoll+0xdb/0x110 [ 736.982908] io_sqpoll_cancel_cb+0x24/0x30 [ 736.982911] io_run_task_work_head+0x28/0x50 [ 736.982913] io_sq_thread+0x4e3/0x720 We call io_uring_cancel_sqpoll() one by one for each ctx either in sq_thread() itself or via task works, and its intended to cancel all requests of a specified context. However the function uses per-task counters to track the number of inflight requests, so it counts more requests than available via currect io_uring ctx and goes to sleep for them to appear (e.g. from IRQ), that will never happen. Cancel a bit more than before, i.e. all ctxs that share sqpoll and continue to use shared counters. Dont forget that we should not remove ctx from the list before running that task_work sqpoll-cancel, otherwise the function wouldnt be able to find the context and will hang.
description
在Linux内核中,已解决以下漏洞:io_uring:修复共享的sqpoll取消挂起[736.982891]信息:任务iou-qp-4294:4295被阻止超过122秒。[736.982897]调用跟踪:[736.982901]schedule+0x68/0xe0[736.98.2903]io_uring_cancel_sqpoll+0xdb/0x110[736.982.908]io_sqpoll_cancel_cb+0x24/0x30[736.982711]io_run_task_work_head+0x28/0x50[736.982213]io_sq_thread+0x4e3/0x720我们在sq_thread()本身或通过任务工作为每个ctx逐个调用io_urint_cancel_squpoll(),其目的是取消指定上下文的所有请求。然而,该函数使用每个任务计数器来跟踪机上请求的数量,因此它统计的请求比通过currect io_uring ctx可用的请求多,并进入睡眠状态等待它们出现(例如,从IRQ),这永远不会发生。比以前多取消一点,即所有共享sqpoll并继续使用共享计数器的ctx。不要忘记,在运行task_work sqpoll cancel之前,我们不应该从列表中删除ctx,否则函数将无法找到上下文,并将挂起。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://git.kernel.org/stable/c/734551df6f9bedfbefcd113ede665945e9de0b99
- https://git.kernel.org/stable/c/cb5e0b3d0f993a6268c1a2c7ede2f9aa0c17ef68
CVE-2021-46943
description
In the Linux kernel, the following vulnerability has been resolved: media: staging/intel-ipu3: Fix set_fmt error handling If there in an error during a set_fmt, do not overwrite the previous sizes with the invalid config. Without this patch, v4l2-compliance ends up allocating 4GiB of RAM and causing the following OOPs [ 38.662975] ipu3-imgu 0000:00:05.0: swiotlb buffer is full (sz: 4096 bytes) [ 38.662980] DMA: Out of SW-IOMMU space for 4096 bytes at device 0000:00:05.0 [ 38.663010] general protection fault: 0000 [#1] PREEMPT SMP
description
在Linux内核中,已解决以下漏洞:media:stating/intel-ip3:修复set_fmt错误处理如果在set_fmt过程中出现错误,请不要用无效的配置覆盖以前的大小。如果没有此修补程序,v4l2合规性最终会分配4GiB的RAM,并导致以下OOP[38.662975]ipu3 imgu 0000:00:05.0:swiotlb缓冲区已满(sz:4096字节)[38.662980]DMA:设备上SW-IOMMU空间不足4096字节0000:00:05.0[38.66300]一般保护故障:0000[#1]PREEMPT SMP
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/34892ea938387d83ffcfb7775ec55f0f80767916
- https://git.kernel.org/stable/c/6fb617e37a39db0a3eca4489431359d0bdf3b9bc
- https://git.kernel.org/stable/c/a03fb1e8a110658215a4cefc3e2ad53279e496a6
- https://git.kernel.org/stable/c/ad91849996f9dd79741a961fd03585a683b08356
- https://git.kernel.org/stable/c/c6b81b897f6f9445d57f8d47c4e060ec21556137
CVE-2021-46944
description
In the Linux kernel, the following vulnerability has been resolved: media: staging/intel-ipu3: Fix memory leak in imu_fmt We are losing the reference to an allocated memory if try. Change the order of the check to avoid that.
description
在Linux内核中,已解决以下漏洞:media:stating/intel-ip3:修复imu_fmt中的内存泄漏如果尝试,我们将丢失对已分配内存的引用。更改检查顺序以避免这种情况发生。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/14d0e99c3ef6b0648535a31bf2eaabb4eff97b9e
- https://git.kernel.org/stable/c/3630901933afba1d16c462b04d569b7576339223
- https://git.kernel.org/stable/c/517f6f570566a863c2422b843c8b7d099474f6a9
- https://git.kernel.org/stable/c/74ba0adb5e983503b18a96121d965cad34ac7ce3
- https://git.kernel.org/stable/c/ff792ae52005c85a2d829c153e08d99a356e007d
CVE-2021-46945
description
In the Linux kernel, the following vulnerability has been resolved: ext4: always panic when errors=panic is specified Before commit 014c9caa29d3 (“ext4: make ext4_abort() use __ext4_error()”), the following series of commands would trigger a panic: 1. mount /dev/sda -o ro,errors=panic test 2. mount /dev/sda -o remount,abort test After commit 014c9caa29d3, remounting a file system using the test mount option “abort” will no longer trigger a panic. This commit will restore the behaviour immediately before commit 014c9caa29d3. (However, note that the Linux kernels behavior has not been consistent; some previous kernel versions, including 5.4 and 4.19 similarly did not panic after using the mount option “abort”.) This also makes a change to long-standing behaviour; namely, the following series commands will now cause a panic, when previously it did not: 1. mount /dev/sda -o ro,errors=panic test 2. echo test > /sys/fs/ext4/sda/trigger_fs_error However, this makes ext4s behaviour much more consistent, so this is a good thing.
description
在Linux内核中,以下漏洞已被解决:ext4:当指定errors=panic时总是panic在提交014c9caa29d3(“ext4:使ext4_abort()使用__ext4_error()”)之前,以下一系列命令将触发panic:1。挂载/dev/sda-o-ro,errors=panic test 2。mount/dev/sda-o重新装载,中止测试在提交014c9caa29d3之后,使用测试装载选项“中止”重新装载文件系统将不再引发恐慌。此提交将立即恢复提交014c9caa29d3之前的行为。(但是,请注意,Linux内核的行为并不一致;一些以前的内核版本,包括5.4和4.19,在使用装载选项“abort”后也没有死机。)这也改变了长期存在的行为;也就是说,以下系列命令现在将引起恐慌,而以前没有:1。挂载/dev/sda-o-ro,errors=panic test 2。echo-test>/sys/fs/ext4/sda/trigger_fs_error然而,这使ext4的行为更加一致,所以这是一件好事。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/1e9ea8f4637026b8e965128953f2da061ccae9c4
- https://git.kernel.org/stable/c/64e1eebe2131183174f4fbb6b1491355f96c6cde
- https://git.kernel.org/stable/c/ac2f7ca51b0929461ea49918f27c11b680f28995
CVE-2021-46946
description
In the Linux kernel, the following vulnerability has been resolved: ext4: fix check to prevent false positive report of incorrect used inodes Commit <50122847007> (“ext4: fix check to prevent initializing reserved inodes”) check the block group zero and prevent initializing reserved inodes. But in some special cases, the reserved inode may not all belong to the group zero, it may exist into the second group if we format filesystem below. mkfs.ext4 -b 4096 -g 8192 -N 1024 -I 4096 /dev/sda So, it will end up triggering a false positive report of a corrupted file system. This patch fix it by avoid check reserved inodes if no free inode blocks will be zeroed.
description
在Linux内核中,已解决以下漏洞:ext4:fix-check以防止错误使用的索引节点的误报Commit<50122847007>(“ext4:fix-check以防止初始化保留的索引节点”)检查块组零并防止初始化保留索引节点。但在某些特殊情况下,保留的inode可能不都属于零组,如果我们格式化下面的文件系统,它可能存在于第二组中。mkfs.ext4-b 4096-g 8192-N 1024-I 4096/dev/sda因此,它最终会触发损坏文件系统的误报报告。此修补程序通过避免检查保留的索引节点来修复此问题,如果没有可用的索引节点块将被置零。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 10.59% |
references
- https://git.kernel.org/stable/c/098b257563b959f4ca6c1d82fde0ee727792cb19
- https://git.kernel.org/stable/c/539ba4ebc467260225898e67ea53cbb73308f894
- https://git.kernel.org/stable/c/7687f5aba0f50c7ff8040e506bae184e59c8e7b8
- https://git.kernel.org/stable/c/9c61387630a54e35b96a90608aafd369ffb86f39
- https://git.kernel.org/stable/c/a149d2a5cabbf6507a7832a1c4fd2593c55fd450
- https://git.kernel.org/stable/c/d2e121be8d318524a61e13ca15b5bfab2d0b63c7
- https://git.kernel.org/stable/c/e18d76a12b34791bc0318a0e0c0fa5863cd8dabf
- https://git.kernel.org/stable/c/e70db6e43286a17c3dfc840fcee662de183b6a81
- https://git.kernel.org/stable/c/f42789ee5f96743cdb5f69445cab3609458733f7
CVE-2021-46947
description
In the Linux kernel, the following vulnerability has been resolved: sfc: adjust efx->xdp_tx_queue_count with the real number of initialized queues efx->xdp_tx_queue_count is initially initialized to num_possible_cpus() and is later used to allocate and traverse efx->xdp_tx_queues lookup array. However, we may end up not initializing all the array slots with real queues during probing. This results, for example, in a NULL pointer dereference, when running “# ethtool -S ”, similar to below [2570283.664955][T4126959] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [2570283.681283][T4126959] #PF: supervisor read access in kernel mode [2570283.695678][T4126959] #PF: error_code(0x0000) - not-present page [2570283.710013][T4126959] PGD 0 P4D 0 [2570283.721649][T4126959] Oops: 0000 [#1] SMP PTI [2570283.734108][T4126959] CPU: 23 PID: 4126959 Comm: ethtool Tainted: G O 5.10.20-cloudflare-2021.3.1 #1 [2570283.752641][T4126959] Hardware name: [2570283.781408][T4126959] RIP: 0010:efx_ethtool_get_stats+0x2ca/0x330 [sfc] [2570283.796073][T4126959] Code: 00 85 c0 74 39 48 8b 95 a8 0f 00 00 48 85 d2 74 2d 31 c0 eb 07 48 8b 95 a8 0f 00 00 48 63 c8 49 83 c4 08 83 c0 01 48 8b 14 ca <48> 8b 92 f8 00 00 00 49 89 54 24 f8 39 85 a0 0f 00 00 77 d7 48 8b [2570283.831259][T4126959] RSP: 0018:ffffb79a77657ce8 EFLAGS: 00010202 [2570283.845121][T4126959] RAX: 0000000000000019 RBX: ffffb799cd0c9280 RCX: 0000000000000018 [2570283.860872][T4126959] RDX: 0000000000000000 RSI: ffff96dd970ce000 RDI: 0000000000000005 [2570283.876525][T4126959] RBP: ffff96dd86f0a000 R08: ffff96dd970ce480 R09: 000000000000005f [2570283.892014][T4126959] R10: ffffb799cd0c9fff R11: ffffb799cd0c9000 R12: ffffb799cd0c94f8 [2570283.907406][T4126959] R13: ffffffffc11b1090 R14: ffff96dd970ce000 R15: ffffffffc11cd66c [2570283.922705][T4126959] FS: 00007fa7723f8740(0000) GS:ffff96f51fac0000(0000) knlGS:0000000000000000 [2570283.938848][T4126959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2570283.952524][T4126959] CR2: 00000000000000f8 CR3: 0000001a73e6e006 CR4: 00000000007706e0 [2570283.967529][T4126959] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [2570283.982400][T4126959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [2570283.997308][T4126959] PKRU: 55555554 [2570284.007649][T4126959] Call Trace: [2570284.017598][T4126959] dev_ethtool+0x1832/0x2830 Fix this by adjusting efx->xdp_tx_queue_count after probing to reflect the true value of initialized slots in efx->xdp_tx_queues.
description
在Linux内核中,已解决以下漏洞:sfc:adjust efx->xdp_tx_queue_count with the real number of initialized queues efx->xdp_tx_queue count最初初始化为num_possible_cpus(),后来用于分配和遍历efx->xdp_tx queues查找数组。但是,在探测过程中,我们可能最终没有用实际队列初始化所有阵列插槽。例如,这会导致在运行“#ethtool-S”时出现空指针取消引用,类似于下面的[2570283664955][T4126959]BUG:内核空指针取消指代,地址:00000000000000f8[25702836681283][T41261959]#PF:内核模式下的主管读取访问[2570283695678][T4126959]#PF:error_code(0x0000)-不存在页面[25700283.710013][T4126959]PGD 0 P4D 0[257002833.721649][T412959]错误:0000[#1]SMP PTI[25700283.334108][T412695]CPU:23 PID:416959 Comm:ethtool Tained:G O 5.10.20-cloudflare-2021.3.1#1[25700243.752641][T412659]硬件名称:<redated>[25700237.781408][T421659]RIP:0010:efx_ethtool_get_stats+0x2ca/0x330[sfc][2570283.796073][T4126959]代码:00 85 c0 74 39 48 8b 95 a8 0f 00 48 85 d2 74 2d 31 c0 eb 07 48 8b 95a8 0f00 48 63 c8 49 83 c4 08 83 c0 01 48 8b 14 ca<48>8b 92 f8 00 00 49 89 54 24 f8 39 85 a0 0f 00 77 d7 48 8b[25700283.831259][T4126959]RSP:0018:ffffffb79a77657ce8 EFLAGS:000010202[257002833.845121][T4126959]RAX:00000000000000019 RBX:ffffb799cd0c9280 RCX:00000000000000018[2570238360872][T4126959]RDX:0000000000000000 RSI:ffff96dd970ce000 RDI:000000000000000 5[25700283.876525][T4126959]RBP:fff96dd86f0a0000 R08:ffff96dd970ce480 R09:000000000000005f[257002833.892014][T4126959]R10:fffffb799cd0c9fff R11:ffffffb79cd0c9000 R12:fffffff799cd0C94f8[2570023907406][T412659]R13:ffffffffff c11b1090 R14:ffff96DD 970ce000 R15:ffffffff c11cd66c【2570283.922705】【T4126959】FS:00007fa7723f8740(0000)GS:fffff96f51fac0000DR3:000000000000000000000000 DR6:00000000 fffe0f0 DR7:0000000000000400[2570283.997308][T4126959]PKRU:55555555 4[2570284.007649][T4126959]调用跟踪:[25702284017598][T4126959]dev_ethtool+0x1832/0x2830通过在探测后调整efx->xdp_tx_queue_count来解决此问题,以反映efx->x_tx_queues中初始化插槽的真实值。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://git.kernel.org/stable/c/99ba0ea616aabdc8e26259fd722503e012199a76
- https://git.kernel.org/stable/c/ebeac958b690123a0b40aa61f688f2f170035fad
CVE-2021-46948
description
In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX event handling Were starting from a TXQ label, not a TXQ type, so efx_channel_get_tx_queue() is inappropriate (and could return NULL, leading to panics).
description
在Linux内核中,已解决以下漏洞:sfc:farch:修复TX事件处理中的TX队列查找Were从TXQ标签而非TXQ类型启动,因此efx_channel_get_TX_queue()不合适(可能返回NULL,导致死机)。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/35c7a83ad1bb1d48ae249346e61b1132bcbf9052
- https://git.kernel.org/stable/c/83b09a1807415608b387c7bc748d329fefc5617e
- https://git.kernel.org/stable/c/bf2b941d0a6f2d3b9f5fa3c4c21bdd54f71ce253
- https://git.kernel.org/stable/c/e531db1ea6f98c9612cb2de093a107c7eadfb96c
CVE-2021-46949
description
In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX flush done handling Were starting from a TXQ instance number (qid), not a TXQ type, so efx_get_tx_queue() is inappropriate (and could return NULL, leading to panics).
description
在Linux内核中,已解决以下漏洞:sfc:farch:修复TX刷新完成处理中的TX队列查找Were从TXQ实例号(qid)开始,而不是从TXQ类型开始,因此efx_get_TX_queue()不合适(可能返回NULL,导致死机)。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/5b1faa92289b53cad654123ed2bc8e10f6ddd4ac
- https://git.kernel.org/stable/c/98d91180748986bfb6dfb3e72765f3225719a647
- https://git.kernel.org/stable/c/a1570985ec04116cc665b760faf666a104154170
- https://git.kernel.org/stable/c/fb791572d6747ef385f628450f8d57cd132e6e5a
CVE-2021-46950
description
In the Linux kernel, the following vulnerability has been resolved: md/raid1: properly indicate failure when ending a failed write request This patch addresses a data corruption bug in raid1 arrays using bitmaps. Without this fix, the bitmap bits for the failed I/O end up being cleared. Since we are in the failure leg of raid1_end_write_request, the request either needs to be retried (R1BIO_WriteError) or failed (R1BIO_Degraded).
description
在Linux内核中,已解决以下漏洞:md/raid1:在结束失败的写入请求时正确指示失败此修补程序使用位图解决了raid1数组中的数据损坏错误。如果没有此修复程序,失败I/O的位图位最终会被清除。由于我们处于raid1_end_write_request的失败阶段,因此需要重试该请求(R1BIO_WriteError)或失败(R1BIO_Graded)。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 8.10% |
references
- https://git.kernel.org/stable/c/12216d0919b64ee2ea5dc7a50e455670f44383d5
- https://git.kernel.org/stable/c/2417b9869b81882ab90fd5ed1081a1cb2d4db1dd
- https://git.kernel.org/stable/c/538244fba59fde17186322776247cd9c05be86dd
- https://git.kernel.org/stable/c/59452e551784b7a57a45d971727e9db63b192515
- https://git.kernel.org/stable/c/661061a45e32d8b2cc0e306da9f169ad44011382
- https://git.kernel.org/stable/c/6920cef604fa57f9409e3960413e9cc11f5c5a40
- https://git.kernel.org/stable/c/a6e17cab00fc5bf85472434c52ac751426257c6f
CVE-2021-46951
description
In the Linux kernel, the following vulnerability has been resolved: tpm: efi: Use local variable for calculating final log size When tpm_read_log_efi is called multiple times, which happens when one loads and unloads a TPM2 driver multiple times, then the global variable efi_tpm_final_log_size will at some point become a negative number due to the subtraction of final_events_preboot_size occurring each time. Use a local variable to avoid this integer underflow. The following issue is now resolved: Mar 8 15:35:12 hibinst kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Mar 8 15:35:12 hibinst kernel: Workqueue: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy] Mar 8 15:35:12 hibinst kernel: RIP: 0010:__memcpy+0x12/0x20 Mar 8 15:35:12 hibinst kernel: Code: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 Mar 8 15:35:12 hibinst kernel: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206 Mar 8 15:35:12 hibinst kernel: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ffffffffffffe0f Mar 8 15:35:12 hibinst kernel: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d Mar 8 15:35:12 hibinst kernel: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000000007e9d6073 Mar 8 15:35:12 hibinst kernel: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5 Mar 8 15:35:12 hibinst kernel: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018 Mar 8 15:35:12 hibinst kernel: FS: 0000000000000000(0000) GS:ffff88f87bd00000(0000) knlGS:0000000000000000 Mar 8 15:35:12 hibinst kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 8 15:35:12 hibinst kernel: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0 Mar 8 15:35:12 hibinst kernel: Call Trace: Mar 8 15:35:12 hibinst kernel: tpm_read_log_efi+0x152/0x1a7 Mar 8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0 Mar 8 15:35:12 hibinst kernel: tpm_chip_register+0x8f/0x260 Mar 8 15:35:12 hibinst kernel: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy] Mar 8 15:35:12 hibinst kernel: process_one_work+0x1b4/0x370 Mar 8 15:35:12 hibinst kernel: worker_thread+0x53/0x3e0 Mar 8 15:35:12 hibinst kernel: ? process_one_work+0x370/0x370
description
在Linux内核中,已经解决了以下漏洞:tpm:efi:使用本地变量计算最终日志大小当多次调用tpm_read_log_efi时,当一个人多次加载和卸载TPM2驱动程序时,就会发生这种情况,则全局变量efi_tpm_final_log_size将在某个时刻由于每次发生的final_events_preboot_size的减法而变为负数。使用局部变量来避免此整数下溢。以下问题现已解决:3月8日15:35:12 hibinst内核:硬件名称:QEMU Standard PC(Q35+ICH92009),BIOS 0.0.0 2015年6月2日3月8日电15:35:12 hibinst kernel:工作队列:tpm vtpm vtpm_proxy_work[tpm_vtpm_proxy]3月8日15:35:12 hibinst内核:RIP:010:__memcpy+0x12/0x20 3月8月8日13:35:12希伯斯特内核:代码:00 b8 01 00 00 85 d2 74 0a c7 05 44 7b ef 00 00 00 c3 cc cc 66 90 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07<f3>48 a5 89 d1 f3 a4 c3 66 0f 44 00 48 f8 48 88 d1 f3 f4 3 3 3 3月8日本斯内核:RSP:0018:ffff9ac4c0fcfde0 EFLAGS:000010206 3月8日15:35:12 hibinst内核:RAX:ffff88f878cefed5 RBX:ffff 88f878Ce9000 RCX:1ffffffffff fffffe0f 3月8日15:35:12 hibinst内核:RDX:000000000000000 3 RSI:ffffff9ac4c003bff9 RDI:ffffff 88f 878cf0e4d 3月8日15:35:12 hibinst核:RBP:ffffff9 ac4c003b000 R08:000000000000 1000 R09:00000000 7e9d6073 3月8月8日13:35:12 500 R12:00000000000000 ed5 3月8日15:35:12 hibinst内核:R13:ffff88f878ce9760 R14:000000000000000 2 R15:ffff88f47de7f018年3月8日15:35:12 hibinst内核:FS:000000000000000000000000(0000)GS:ffff88f 87bd00000(0000)knlGS:0000000000000000000000000 3月8日15:35:12 hibinst内核:CS:0010 DS:0000 ES:00000 CR:000000000 80050033 3月8日15:35:12 hibinst核:CR2:ffff9ac4c003c000 CR3:0000000 1785a6004 CR4:00000000000 60ee0 3月8日日15:35:12hibinst核心:调用跟踪:3月8日间15:35:12Hibinst内核:tpm_read_log_efi+0x152/0x1a7 3月8日夜15:35:12希伯斯特内核:tpm_bios_log_setup+0xc8/0x1c0:tpm_chip_register+0x8f/0x260 3月8日15:35:12 hibinst内核:vtpm_proxy_work+0x16/0x60[tpm_vtpm_proxy]3月8月8日13:35:12希伯斯特内核:process_one_work+0x1b4/0x370 3月8日电15:35:122 hibinst kernel:worker_thread+0x53/0x3e0 3月8日本斯内核:?process_one_work+0x370/0x370
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/2f12258b5224cfaa808c54fd29345f3c1cbfca76
- https://git.kernel.org/stable/c/3818b753277f5ca0c170bf5b98e0a5a225542fcb
- https://git.kernel.org/stable/c/48cff270b037022e37835d93361646205ca25101
- https://git.kernel.org/stable/c/60a01ecc9f68067e4314a0b55148e39e5d58a51b
- https://git.kernel.org/stable/c/ac07c557ca12ec9276c0375517bac7ae5be4e50c
CVE-2021-46952
description
In the Linux kernel, the following vulnerability has been resolved: NFS: fs_context: validate UDP retrans to prevent shift out-of-bounds Fix shift out-of-bounds in xprt_calc_majortimeo(). This is caused by a garbage timeout (retrans) mount option being passed to nfs mount, in this case from syzkaller. If the protocol is XPRT_TRANSPORT_UDP, then retrans is a shift value for a 64-bit long integer, so retrans cannot be >= 64. If it is >= 64, fail the mount and return an error.
description
在Linux内核中,已解决以下漏洞:NFS:fs_config:validate UDP retrans以防止移位越界修复xprt_calc_majortimeo()中的移位越界。这是由于垃圾超时(retrans)装载选项被传递到nfs装载,在本例中是从syzkaller传递的。如果协议是XPRT_TRANSPORT_UDP,则retrans是64位长整数的移位值,因此retrans不能>=64。如果它>=64,则装载失败并返回错误。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/2f3380121d49e829fb73ba86240c181bc32ad897
- https://git.kernel.org/stable/c/3d0163821c035040a46d816a42c0780f0f0a30a8
- https://git.kernel.org/stable/c/96fa26b74cdcf9f5c98996bf36bec9fb5b19ffe2
- https://git.kernel.org/stable/c/c09f11ef35955785f92369e25819bf0629df2e59
CVE-2021-46953
description
In the Linux kernel, the following vulnerability has been resolved: ACPI: GTDT: Dont corrupt interrupt mappings on watchdow probe failure When failing the driver probe because of invalid firmware properties, the GTDT driver unmaps the interrupt that it mapped earlier. However, it never checks whether the mapping of the interrupt actially succeeded. Even more, should the firmware report an illegal interrupt number that overlaps with the GIC SGI range, this can result in an IPI being unmapped, and subsequent fireworks (as reported by Dann Frazier). Rework the driver to have a slightly saner behaviour and actually check whether the interrupt has been mapped before unmapping things.
description
在Linux内核中,已解决以下漏洞:ACPI:GTDT:不要在watchdow探测失败时破坏中断映射当由于固件属性无效而导致驱动程序探测失败时,GTDT驱动程序会取消映射先前映射的中断。然而,它从不检查中断的映射是否实际成功。更重要的是,如果固件报告了与GIC SGI范围重叠的非法中断编号,这可能会导致IPI被取消映射,以及随后的焰火(如Dann Frazier所报告的)。重新调整驱动程序,使其行为稍微理智一点,并在取消映射之前实际检查中断是否已映射。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 8.10% |
references
- https://git.kernel.org/stable/c/1ecd5b129252249b9bc03d7645a7bda512747277
- https://git.kernel.org/stable/c/42e69521ee1fa5abf21f478d147d06bbfe6bf6a8
- https://git.kernel.org/stable/c/504632a3577a049dd9bb7aabae5b4476f9c586b4
- https://git.kernel.org/stable/c/596e079c362ac17ed02aa1b99fdc444d62072a01
- https://git.kernel.org/stable/c/7b2162db1498c71962a4bb2f776fa4e76d4d305b
- https://git.kernel.org/stable/c/c3385a9122f8db15b453e07bfc88117fce7f3724
- https://git.kernel.org/stable/c/e0f2d86481eaa83df33b0793f75212919db7a19d
CVE-2021-46954
description
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_frag: fix stack OOB read while fragmenting IPv4 packets when act_mirred tries to fragment IPv4 packets that had been previously re-assembled using act_ct, splats like the following can be observed on kernels built with KASAN: BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60 Read of size 1 at addr ffff888147009574 by task ping/947 CPU: 0 PID: 947 Comm: ping Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 sch_fragment+0x4bf/0xe40 tcf_mirred_act+0xc3d/0x11a0 [act_mirred] tcf_action_exec+0x104/0x3e0 fl_classify+0x49a/0x5e0 [cls_flower] tcf_classify_ingress+0x18a/0x820 __netif_receive_skb_core+0xae7/0x3340 __netif_receive_skb_one_core+0xb6/0x1b0 process_backlog+0x1ef/0x6c0 __napi_poll+0xaa/0x500 net_rx_action+0x702/0xac0 __do_softirq+0x1e4/0x97f do_softirq+0x71/0x90 __local_bh_enable_ip+0xdb/0xf0 ip_finish_output2+0x760/0x2120 ip_do_fragment+0x15a5/0x1f60 __ip_finish_output+0x4c2/0xea0 ip_output+0x1ca/0x4d0 ip_send_skb+0x37/0xa0 raw_sendmsg+0x1c4b/0x2d00 sock_sendmsg+0xdb/0x110 __sys_sendto+0x1d7/0x2b0 __x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f82e13853eb Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89 RSP: 002b:00007ffe01fad888 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00005571aac13700 RCX: 00007f82e13853eb RDX: 0000000000002330 RSI: 00005571aac13700 RDI: 0000000000000003 RBP: 0000000000002330 R08: 00005571aac10500 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe01faefb0 R13: 00007ffe01fad890 R14: 00007ffe01fad980 R15: 00005571aac0f0a0 The buggy address belongs to the page: page:000000001dff2e03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x147009 flags: 0x17ffffc0001000(reserved) raw: 0017ffffc0001000 ffffea00051c0248 ffffea00051c0248 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888147009400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888147009480: f1 f1 f1 f1 04 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 >ffff888147009500: 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 f2 ^ ffff888147009580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888147009600: 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 for IPv4 packets, sch_fragment() uses a temporary struct dst_entry. Then, in the following call graph: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() the pointer to struct dst_entry is used as pointer to struct rtable: this turns the access to struct members like rt_mtu_locked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in sch_fragment(), similarly to what is done for IPv6 few lines below.
description
在Linux内核中,已解决以下漏洞:net/sched:sch_frag:fix当act_mirred试图对先前使用act_ct重新组装的IPv4数据包进行分段时,在对IPv4数据包分段时读取堆栈OOB,在使用KASAN构建的内核上可以观察到如下飞溅:BUG:KASAN:在ip_do_fragment+0x1b03/0x1f60中堆栈越界通过任务ping/947 CPU:0 PID:947 Comm:ping读取addr ffffff888147009574处的大小1硬件名称:Red Hat KVM,BIOS 1.11.1-4.module+el8.1.0+4066+0f1adab 04/01/2014调用跟踪:dump_stack+0x92/0xc1 print_addressdescription.constprop.7+0x1a/0x150 kasan_report.cocold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 sch_fragement+0x4bf/0xe40 tcf_mirred_act+0xc3d/0x11a0[act_mirred]tcf_action_exec+0x104/0x3e0 fl_classification+0x49a/0x5e0[cls_flower]tcf_分类_入口+0x18a/0x820 __netif_接收_skb_core+0xae7/0x32340 __netif_ereceive_skb_one_core+0xb6/0x1b0进程_备份日志+0x1ef/0x6c0 __napi_poll+0xaa/0x500 net_rx_action+0x702/0xac0 __do_softirq+0x1e4/0x97f do_softir q+0x71/0x90__local_bh_enable_ip+0xdb/0xf0 ip_finish_output2+0x760/0x2120 ip_do_fragment+0x15a/0x1f60 __ip _完成输出+0x4c2/0xea0 ip_output+0x1ca/0x4d0ip_send_skb+0x37/0xa0 raw_sendmsg+0x1c4b/0x2d00 sock_sendmsg=0xdb/0x110 __sys_sendto+0x1d7/0x2b0__x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0x33/0x40 entry_syscall_64_after_hwframe+0x44/0xae RIP:003:00x7f82e13853eb代码:66 2e 0f 1f 84 00 00 00 00 0f 1 f 44 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c 0 75 14 b8 2c 00 00 0 f 05<48>3d 00 f0 ff 77 75 c3 0 f 40 00 41 57 4d 89c7 41 56 41 89 RSP:002b:00007ffe01fad888 EFLAGS:000000246 ORIG_RAX:0000000000000002c RAX:fffffffffff da RBX:00005571ac13700 RCX:00007f82e13853eb RDX:0000000000000 2330 RSI:00005571ac1.3700 RDI:000000000000000 3 RBP:0000000000000 233 0 R08:00005571ac 10500 R09:0000000000000010 R10:000000000000000000000000000000000 R11:0000000000000246 R12:00007ffe01 faefb0 R13:00007ffe01fad890 R14:00007ffe01 fad980 R15:00005571ac0f0a0错误地址属于页面:页面:000000001dff2e03参考计数:1映射计数:0映射:0000000000000000索引:0x0 pfn:0x147009标志:0x17ffffc0001000(保留)原始:0017ffffc0001000 ffffea00051c0248 ffffea0005 1c0248 000000000000000000000000原始:000000000000000000000000000000000000000 1fffffff 00000000000000000000000000000页面转储原因:kasan:检测到错误访问错误地址周围的内存状态:ffffff888147009400:000 00 00 00 000 00 00 00 0 00 00 00 00fffffffff888147009480:f1 f1 f1 f1 f1 04 f2 f2 f2 f2 f1 f2 f2 00 00 00>ffffffff 888147009500:000 00 000 000 00 0000 00 00 00 f2 f2 f2 f2^ffff888147009580:000 00 00 000 00 00 00 0 00 00 00 0000 00 00 ffffff888147 009600:000 00 000 000 00 00 00.00 00 00 00对于IPv4数据包,sch_fragment()使用临时结构dst_entry。然后,在以下调用图中:ip_do_fragment()ip_skb_dst_mtu()ip_dst_mtu_maybe_forward()ip_mtu_locked()将指向结构dst_entry的指针用作指向结构rtable的指针:这将对结构成员(如rt_mtu_lock)的访问转换为堆栈中的OOB读取。修复在sch_fragment()中更改用于IPv4数据包的临时变量的问题,类似于下面几行对IPv6所做的操作。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/018bb8da5b5888e19585f9b802f036afe643fcef
- https://git.kernel.org/stable/c/31fe34a0118e0acc958c802e830ad5d37ef6b1d3
- https://git.kernel.org/stable/c/8e6dfb7beeb6489ac1365b8a71052e737f5da76e
CVE-2021-46955
description
In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix stack OOB read while fragmenting IPv4 packets running openvswitch on kernels built with KASAN, its possible to see the following splat while testing fragmentation of IPv4 packets: BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60 Read of size 1 at addr ffff888112fc713c by task handler2/1367 CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 ovs_fragment+0x5bf/0x840 [openvswitch] do_execute_actions+0x1bd5/0x2400 [openvswitch] ovs_execute_actions+0xc8/0x3d0 [openvswitch] ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch] genl_family_rcv_msg_doit.isra.15+0x227/0x2d0 genl_rcv_msg+0x287/0x490 netlink_rcv_skb+0x120/0x380 genl_rcv+0x24/0x40 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f957079db07 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0 The buggy address belongs to the page: page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7 flags: 0x17ffffc0000000() raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame: ovs_fragment+0x0/0x840 [openvswitch] this frame has 2 objects: [32, 144) ovs_dst [192, 424) ovs_rt Memory state around the buggy address: ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 ^ ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then, in the following call graph: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() the pointer to struct dst_entry is used as pointer to struct rtable: this turns the access to struct members like rt_mtu_locked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in ovs_fragment(), similarly to what is done for IPv6 few lines below.
description
在Linux内核中,已解决以下漏洞:openvswitch:修复在使用KASAN构建的内核上分割运行openvswitch的IPv4数据包时读取的堆栈OOB,在测试IPv4数据包的碎片时,可能会看到以下飞溅:BUG:KASAN:在ip_do_fragment+0x1b03/0x1f60中堆栈越界任务处理程序2/1367 CPU:0 PID:1367 Comm:handler2未受污染5.12.0-rc6+#418硬件名称:Red Hat KVM,BIOS 1.11.1-4.module+el8.1.0+4066+0f1adab 04/01/2014调用跟踪:dumpstack+0x92/0xc1 print_addressdescription.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 ovs_fragment+0x5bf/0x840[openvswitch]do_execute_actions+0x1bd5/0x2400[openvsswitch]ovs_execute_actions+0xc8/0x3d0[openvs切换]ovs_packet_cmd_execute+0xa39/0x1150[openvsSwitch]genl_family_rcv_msg_doit.isra.15+0x227/0x2d0 genl_rcv_msg+0x287/0x490 netlink_rcv_skb+0x120/0x380 genl_rcv+0x24/0x40 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0.x5ba/0x890 ___sys_send msg+0xe9/0x160 __sys_sendmsg=0xd3/0x170 do_syscall_64+0x33/0x40 entry_sys CALL_64_after_hwframe+0x44/0xae RIP:003:0x7f957079db07代码:c3 66 90 41 54 41 89 d4 5548 89 f5 53 89 fb 48 83 ec 10 e8 eb ec-ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 0f 05<48>3d 00 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff 48 RSP:002b:00007f956ce35a50 EFLAGS:000000293 ORIG_RAX:0000000000000002e RAX:ffffffffff ffffff da RBX:0000000000000019 RCX:000007f957079db07 RDX:00000000000000000 RSI:00007f95 6ce35a0e0 RDI:0000000000000019 RBP:00007f956ce35ae0 R08:0000000000000000 R09:00007f9558006730 R10:00000000000000000 R11:0000000000000293 R12:0000000000000000 R13:00007f956ce37308 R14:00007f95.6ce35f80 R15:00007f95 6ce35ae0错误地址属于页面:页面:00000000 af2a1d93 refcount:0 mapcount:0映射:0000000000000000索引:0x0 pfn:0x112fc7标志:0x17ffffc0000000()原始:0017ffffc0000000000000000000000死亡000000000122 0000000000000000原始:00000000000000000000000000000000 ffffff0000000000000000页面转储,因为:kasan:检测到错误访问地址ffff888112fc713c位于任务处理程序2/1367的堆栈中帧中偏移180处:ovs_fragment+0x0/0x840[openvswitch]此帧有两个对象:[32144)ovs_dst[1922424)ovs_rt错误地址周围的内存状态:ffff888112fc7000:f3 00 00 00 00 000 00 00 00 0000 00 00 ffffff888112 fc7080:00 f1 f1 f1 00 00 00 0 00 00 00 01 00 00 00>ffffff888 112fc7100:00 00 00 02 f2 f2 f2 00 00 00 00.00 00 00 ^ffffffff88 112fc7180:00 00 00 00.00 00 00 00 00200 00 00.00 00 00 ffff 888112fc7200:00 00 0000.00 00 f2 00 00 00.00000 00 00 for IPv4数据包,ovs_fragment()使用一个临时结构dst_entry。然后,在以下调用图中:ip_do_fragment()ip_skb_dst_mtu()ip_dst_mtu_maybe_forward()ip_mtu_locked()将指向结构dst_entry的指针用作指向结构rtable的指针:这将对结构成员(如rt_mtu_lock)的访问转换为堆栈中的OOB读取。修复在ovs_fragment()中更改用于IPv4数据包的临时变量的问题,类似于下面几行对IPv6所做的操作。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 10.59% |
references
- https://git.kernel.org/stable/c/23e17ec1a5eb53fe39cc34fa5592686d5acd0dac
- https://git.kernel.org/stable/c/490ad0a2390442d0a7b8c00972a83dbb09cab142
- https://git.kernel.org/stable/c/5a52fa8ad45b5a593ed416adf326538638454ff1
- https://git.kernel.org/stable/c/7c0ea5930c1c211931819d83cfb157bff1539a4c
- https://git.kernel.org/stable/c/a1478374b0bda89b4277a8afd39208271faad4be
- https://git.kernel.org/stable/c/b1d7280f9ba1bfdbc3af5bdb82e51f014854f26f
- https://git.kernel.org/stable/c/b3502b04e84ac5349be95fc033c17bd701d2787a
- https://git.kernel.org/stable/c/d841d3cf5297fde4ce6a41ff35451d0e82917f3e
- https://git.kernel.org/stable/c/df9e900de24637be41879e2c50afb713ec4e8b2e
CVE-2021-46956
description
In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix memory leak in virtio_fs_probe() When accidentally passing twice the same tag to qemu, kmemleak ended up reporting a memory leak in virtiofs. Also, looking at the log I saw the following error (thats when I realised the duplicated tag): virtiofs: probe of virtio5 failed with error -17 Heres the kmemleak log for reference: unreferenced object 0xffff888103d47800 (size 1024): comm “systemd-udevd”, pid 118, jiffies 4294893780 (age 18.340s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 …..N………. ff ff ff ff ff ff ff ff 80 90 02 a0 ff ff ff ff ……………. backtrace: [<000000000ebb87c1>] virtio_fs_probe+0x171/0x7ae [virtiofs] [<00000000f8aca419>] virtio_dev_probe+0x15f/0x210 [<000000004d6baf3c>] really_probe+0xea/0x430 [<00000000a6ceeac8>] device_driver_attach+0xa8/0xb0 [<00000000196f47a7>] __driver_attach+0x98/0x140 [<000000000b20601d>] bus_for_each_dev+0x7b/0xc0 [<00000000399c7b7f>] bus_add_driver+0x11b/0x1f0 [<0000000032b09ba7>] driver_register+0x8f/0xe0 [<00000000cdd55998>] 0xffffffffa002c013 [<000000000ea196a2>] do_one_initcall+0x64/0x2e0 [<0000000008f727ce>] do_init_module+0x5c/0x260 [<000000003cdedab6>] __do_sys_finit_module+0xb5/0x120 [<00000000ad2f48c6>] do_syscall_64+0x33/0x40 [<00000000809526b5>] entry_SYSCALL_64_after_hwframe+0x44/0xae
description
在Linux内核中,已解决以下漏洞:virtiofs:修复virtio_fs_probe()中的内存泄漏当意外地将两次相同的标记传递给qemu时,kmemleak最终报告了virtiofs中的内存泄露。此外,在查看日志时,我看到了以下错误(那是我意识到重复标记的时候):virtiofs:virtio5的探测失败,出现错误-17这是kmemleak日志供参考:未引用的对象0xffff888103d47800(大小1024):comm“systemd udevd”,pid 118,jiffies 4294893780(年龄18.340s)十六进制转储(前32字节):00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00。。。。。N…………..ff ff ff ff ffff ff ff 80 90 02 a0 ff ff ff。。。。。。。。。。。。。。。。回溯:[<000000000 ebb87c1>]virtio_fs_probe+0x171/0x7ae[virtiofs][<00000000 f8aca419>]virvio_dev_probe+0x15f/0x210[<000000004d6baf3c>]really_probe+0xea/0x430[<00000000a6ceeac8>]device_driver_attach+0xa8/0xb0[<00000000196f47a7>]__driver_attach+0x98/0x140[<000000000b20601d>]bus_for_each_dev+0x7b/0xc0[<00000000399c7b 7f>]总线_驱动程序+0x11b/0x1f0[<00000000 32b09ba7>]driver_register+0x8f/0xe0[<00000000 cdd55998>]0xffffffffa002c013[<000000000 ea196a2>]do_one_initcall+0x64/0x2e0[<000000000 8f727ce>]do_init_module+0x5c/0x260[<000000003 dedab6>]__do_sys_finit_module+0xb5/0x120[<000000 ad2f48c6>]do_syscall_64+0x33/0x40[<00000000809526b5>]entry_syscall_64_after_hwframe+0x44/0xae
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/310efc95c72c13faf855c692d19cd4d054d827c8
- https://git.kernel.org/stable/c/5116e79fc6e6725b8acdad8b7e928a83ab7b47e6
- https://git.kernel.org/stable/c/9b9d60c0eb8ada99cce2a9ab5c15dffc523b01ae
- https://git.kernel.org/stable/c/c79c5e0178922a9e092ec8fed026750f39dcaef4
- https://git.kernel.org/stable/c/d19555ff225d0896a33246a49279e6d578095f15
CVE-2021-46957
description
In the Linux kernel, the following vulnerability has been resolved: riscv/kprobe: fix kernel panic when invoking sys_read traced by kprobe The execution of sys_read end up hitting a BUG_ON() in __find_get_block after installing kprobe at sys_read, the BUG message like the following: [ 65.708663] ————[ cut here ]———— [ 65.709987] kernel BUG at fs/buffer.c:1251! [ 65.711283] Kernel BUG [#1] [ 65.712032] Modules linked in: [ 65.712925] CPU: 0 PID: 51 Comm: sh Not tainted 5.12.0-rc4 #1 [ 65.714407] Hardware name: riscv-virtio,qemu (DT) [ 65.715696] epc : __find_get_block+0x218/0x2c8 [ 65.716835] ra : __getblk_gfp+0x1c/0x4a [ 65.717831] epc : ffffffe00019f11e ra : ffffffe00019f56a sp : ffffffe002437930 [ 65.719553] gp : ffffffe000f06030 tp : ffffffe0015abc00 t0 : ffffffe00191e038 [ 65.721290] t1 : ffffffe00191e038 t2 : 000000000000000a s0 : ffffffe002437960 [ 65.723051] s1 : ffffffe00160ad00 a0 : ffffffe00160ad00 a1 : 000000000000012a [ 65.724772] a2 : 0000000000000400 a3 : 0000000000000008 a4 : 0000000000000040 [ 65.726545] a5 : 0000000000000000 a6 : ffffffe00191e000 a7 : 0000000000000000 [ 65.728308] s2 : 000000000000012a s3 : 0000000000000400 s4 : 0000000000000008 [ 65.730049] s5 : 000000000000006c s6 : ffffffe00240f800 s7 : ffffffe000f080a8 [ 65.731802] s8 : 0000000000000001 s9 : 000000000000012a s10: 0000000000000008 [ 65.733516] s11: 0000000000000008 t3 : 00000000000003ff t4 : 000000000000000f [ 65.734434] t5 : 00000000000003ff t6 : 0000000000040000 [ 65.734613] status: 0000000000000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 65.734901] Call Trace: [ 65.735076] [] __find_get_block+0x218/0x2c8 [ 65.735417] [] __ext4_get_inode_loc+0xb2/0x2f6 [ 65.735618] [] ext4_get_inode_loc+0x3a/0x8a [ 65.735802] [] ext4_reserve_inode_write+0x2e/0x8c [ 65.735999] [] __ext4_mark_inode_dirty+0x4c/0x18e [ 65.736208] [] ext4_dirty_inode+0x46/0x66 [ 65.736387] [] __mark_inode_dirty+0x12c/0x3da [ 65.736576] [] touch_atime+0x146/0x150 [ 65.736748] [] filemap_read+0x234/0x246 [ 65.736920] [] generic_file_read_iter+0xc0/0x114 [ 65.737114] [] ext4_file_read_iter+0x42/0xea [ 65.737310] [] new_sync_read+0xe2/0x15a [ 65.737483] [] vfs_read+0xca/0xf2 [ 65.737641] [] ksys_read+0x5e/0xc8 [ 65.737816] [] sys_read+0xe/0x16 [ 65.737973] [] ret_from_syscall+0x0/0x2 [ 65.738858] —[ end trace fe93f985456c935d ]— A simple reproducer looks like: echo p:myprobe sys_read fd=%a0 buf=%a1 count=%a2 > /sys/kernel/debug/tracing/kprobe_events echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable cat /sys/kernel/debug/tracing/trace Heres what happens to hit that BUG_ON(): 1) After installing kprobe at entry of sys_read, the first instruction is replaced by ebreak instruction on riscv64 platform. 2) Once kernel reach the ebreak instruction at the entry of sys_read, it trap into the riscv breakpoint handler, where it do something to setup for coming single-step of origin instruction, including backup the sstatus in pt_regs, followed by disable interrupt during single stepping via clear SIE bit of sstatus in pt_regs. 3) Then kernel restore to the instruction slot contains two instructions, one is original instruction at entry of sys_read, the other is ebreak. Here it trigger a Instruction page fault exception (value at scause is 0xc), if PF is not filled into PageTabe for that slot yet. 4) Again kernel trap into page fault exception handler, where it choose different policy according to the state of running kprobe. Because afte 2) the state is KPROBE_HIT_SS, so kernel reset the current kp —truncated—
description
在Linux内核中,已解决以下漏洞:riscv/kprobe:修复调用由kprobe跟踪的sys_read时的内核死机在sys_read上安装kprobe后,sys_read的执行最终会在__find_get_block中遇到BUG_ON(),BUG消息如下:[65.708663]—————[剪切此处]—————-[65.709987]fs/buffer.c:1251处的内核BUG![65.711283]内核BUG[#1][65.712032]链接在中的模块:[65.712925]CPU:0 PID:51通信:sh未污染5.12.0-rc4#1[65.71407]硬件名称:riscv virtio,qemu(DT)[65.71569]epc:__find_get_block+0x218/0x2c8[65.716835]ra:__getblk_gfp+0x1c/0x4a[65.717831]epc:ffffff e0019f11e ra:ffff e00019f56a sp:fffff e02437930[65.7155553]gp:fffffff e00f06030 tp:fffff e015abc00 t0:ffffff e0191e038[65.721290]t1:fffff e 0191e038 t2:000000000000000 a s0:ffffff e 02437960[65.725051]s1:fffff f e0160ad00 a0:ffffffff e 0160ad00a1:000000000000012a[65.724772]a2:00000000000000400 a3:0000000000000000 8 a4:0000000000000040[65.726545]a5:000000000000000000000000000000000 a6:ffffff e20191e000 a7:0000000000000000000000[65.724545]728308]s2:000000000000012a s3:0000000000000400 s4:000000000000000 8[65.730049]s5:000000000000006c s6:ffffff e00240f800 s7:ffffff e 000f080a8[65.731802]s8:000000000000000 1 s9:000000000000012 a s10:00000000000000 8[65.73516]s11:000000000000000 8t3:00000000000003 f t4:000000000000000f[65.734434]t5:00000000000003f t6:0000000000000040000[65.734613]状态:0000000000000100 badaddr:0000000000000000原因:000000000000000 3[65.734901]调用跟踪:[65.735076][]__find_get_block+0x218/0x2c8[65.735117][]__ext4_get_inode_loc+0x22/0x2f6[65.735118][<ffffff e 00201b6c>]ext4_get_inode_loc+0.3a/0x8a[65.735802][]ext4_reserve_node_write+0x2e/0x8c[65.735999][]__ext4_mark_inode_dirty+0x4c/0x18e[65.736208][]ext4_dirty_inode+0x46/0x66[65.736387][]__mark_inode_dirty+0x2c/0x3da[65.736576][]touch_atime+0x146/0x150[65.736748][]filemap_read+0x234/0x246[65.736920][<夫e0010d834>]generic_file_read ad_iter+0xc0/0x114[65.773114][]ext4_file_read_iter+0x42/0xea[65.7737310][]new_sync_read+0xe2/0x15a[65.7737483][]vfs_read+0xca/0xf2[65.7737641][]ksys_read+0x5e/0xc8[65.7737816][]sys_read+0x/0x16[65.7737973][]ret_from_syscall+0x0/0x2[65.738858]-[结束跟踪fe93f985456c935d]—一个简单的复制器看起来像:echo p:myprobe sys_read fd=%a0 buf=%a1 count=%a2>/sys/kernel/debug/tracing/kprobe_events echo 1>/sys/kernel/debug/tracing/enable-cat/sys/kernel/debug/tracing/trace以下是BUG_ON()遇到的情况:1)在sys_read的入口安装kprobe后,第一条指令在riscv64平台上被ebreak指令取代。2) 一旦内核在sys_read的入口到达ebreak指令,它就会进入riscv断点处理程序,在那里它会为即将到来的源指令的单步执行进行设置,包括备份pt_regs中的sstatus,然后在单步执行期间通过清除pt_regs中sstatus的SIE位禁用中断。3) 然后内核恢复到指令槽包含两条指令,一条是sys_read入口的原始指令,另一条是ebreak。在这里,如果PF还没有填充到该插槽的PageTabe中,它会触发指令页错误异常(scause处的值为0xc)。4) 再次,内核陷阱进入页面错误异常处理程序,根据运行kprobe的状态选择不同的策略。因为afte 2)的状态是KPROBE_HIT_SS,所以内核重置当前的kp—-截断—
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://git.kernel.org/stable/c/b1ebaa0e1318494a7637099a26add50509e37964
- https://git.kernel.org/stable/c/fd0f06590d35c99f98d12c7984897ec4201a6263
CVE-2021-46958
description
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between transaction aborts and fsyncs leading to use-after-free There is a race between a task aborting a transaction during a commit, a task doing an fsync and the transaction kthread, which leads to an use-after-free of the log root tree. When this happens, it results in a stack trace like the following: BTRFS info (device dm-0): forced readonly BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS: error (device dm-0) in cleanup_transaction:1958: errno=-5 IO failure BTRFS warning (device dm-0): lost page write due to IO error on /dev/mapper/error-test (-5) BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10 BTRFS error (device dm-0): error writing primary super block to device 1 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e010 len 4096 err no 10 BTRFS: error (device dm-0) in write_all_supers:4110: errno=-5 IO failure (1 errors while writing supers) BTRFS: error (device dm-0) in btrfs_sync_log:3308: errno=-5 IO failure general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-next-84 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x139/0xa40 Code: c0 74 19 (…) RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202 RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 0000000000000002 RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff9f18830d7bc0 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040 R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358 FS: 00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __btrfs_handle_fs_error+0xde/0x146 [btrfs] ? btrfs_sync_log+0x7c1/0xf20 [btrfs] ? btrfs_sync_log+0x7c1/0xf20 [btrfs] btrfs_sync_log+0x7c1/0xf20 [btrfs] btrfs_sync_file+0x40c/0x580 [btrfs] do_fsync+0x38/0x70 __x64_sys_fsync+0x10/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fa9142a55c3 Code: 8b 15 09 (…) RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c3 RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000340 R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0 Modules linked in: btrfs dm_zero dm_snapshot dm_thin_pool (…) —[ end trace ee2f1b19327d791d ]— The steps that lead to this crash are the following: 1) We are at transaction N; 2) We have two tasks with a transaction handle attached to transaction N. Task A and Task B. Task B is doing an fsync; 3) Task B is at btrfs_sync_log(), and has saved fs_info->log_root_tree into a local variable named log_root_tree at the top of btrfs_sync_log(). Task B is about to call write_all_supers(), but before that… 4) Task A calls btrfs_commit_transaction(), and after it sets the transaction state to TRANS_STATE_COMMIT_START, an error happens before it w —truncated—
description
在Linux内核中,已解决以下漏洞:btrfs:fix事务中止和fsyncs之间的竞争导致释放后使用在提交期间中止事务的任务、执行fsync的任务和事务kthread之间存在竞争,后者导致释放日志根树后使用。当这种情况发生时,它会导致如下堆栈跟踪:BTRFS信息(设备dm-0):强制只读BTRFS警告(设备dm-0):跳过中止事务的提交。BTRFS:cleanup_transaction:1958:errno=-5 IO失败BTRFS警告(设备dm-0):由于/dev/mapper/error test上的IO错误而丢失页面写入(-5)BTRFS警报(设备dm-0):跳过已中止事务的提交。BTRFS警告(设备dm-0 _supers:4110:errno=-5 IO故障(写入supers时出现1个错误)BTRFS:BTRFS_sync_log:3308中的错误(设备dm-0):errno=-5IO故障一般保护故障,可能是针对非规范地址0x6b6b6b6b6B6b68:0000[#1]PREEMPT SMP DEBUG_PAGELOC PTI CPU:2 PID:22458471 Comm:fssstress未受污染5.12.0-rc5-BTRFS-next-84#1硬件名称:QEMU标准PC(i440FX+PIX,1996),BIOS rel-1.14.0-0-g155821a1990b-prebuilt.QEMU.org 2014年1月4日RIP:0010:__mute_lock+0x139/0xa40代码:c0 74 19(…)RSP:0018:fffff9f18830d7b00 EFLAGS:000010202 RAX:6b6b6b6b6bb6b6b68 RBX:0000000000000000 1 RCX:000000000000000000000000 2 RDX:ffffffffff b9c54d13 RSI:000000000000000000000000 RDI:0000000000000000 RBP:fffffff9F18830d7bc0 R08:000000000000000000000000R09:0000000000000000 R10:ffff9f1 8830d7be0 R11:000000000000000 0 1 R12:ffffff8c6cd199c040 R13:ff8c6c95821358 R14:00000000 fffffff b R15:ff ff8c6cbcf01358 FS:00007fa9140c2b80__btrfs_handle_fs_error+0xde/0x146[btrfs]?btrfs_sync_log+0x7c1/0xf20[btrfs]?btrfs_sync_log+0x7c1/0xf20[btrfs]btrfs_sync_log+0x5c1/0xf20[btrfs]btrfs_ync_file+0x40c/0x580[btrfs]do_fsync+0x38/0x70 _x64_sys_fsync+0x10/0x20 do_syscall_64+0x33/0x80 entry_syscall_64_after_hwframe+0x44/0xae RIP:003:0x7fa9142a55c3代码:8b 15 09(…)RSP:002b:00007fff26278d48 EFLAGS:00000246 ORIG_RAX:000000000000004a RAX:fffffffffff da RBX:00000563c83cb4560 RCX:000007fa9142a55c3 RDX:00007fff26278cb0 RSI:00007fff26288cb0 RDI:000000000000000 5 RBP:0000000000000000 0 5 R08:000000000000000 1 R09:00007fff26278d5c R10:00000000000000000 R11:0000000000000246 R12:0000000000000340 R13:00007fff16278de0 R14:00007ffff26278d96 R15:0000563c83 ca57c0模块链接在:btrfs dm zero dm_snapshot dm_thin_pool(…)—[结束跟踪ee2f1b119327d791d]-导致此崩溃的步骤如下:1)我们处于事务N;2) 我们有两个任务,事务N附有一个事务句柄。任务a和任务B。任务B正在进行fsync;3) 任务B位于btrfs_sync_log(),并已将fs_info->log_root_tree保存到位于btrfs_sync_log的顶部名为log_root_tree的局部变量中。任务B即将调用write_all_supers(),但在此之前。。。4) 任务A调用btrfs_commit_transaction(),在将事务状态设置为TRANS_state_commit_START之后,在它被截断之前会发生错误—
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/061dde8245356d8864d29e25207aa4daa0be4d3c
- https://git.kernel.org/stable/c/633f7f216663587f17601eaa1cf2ac3d5654874c
- https://git.kernel.org/stable/c/a4794be7b00b7eda4b45fffd283ab7d76df7e5d6
- https://git.kernel.org/stable/c/e2da98788369bfba1138bada72765c47989a4338
CVE-2021-46960
description
In the Linux kernel, the following vulnerability has been resolved: cifs: Return correct error code from smb2_get_enc_key Avoid a warning if the error percolates back up: [440700.376476] CIFS VFS: \otters.example.com crypt_message: Could not get encryption key [440700.386947] ————[ cut here ]———— [440700.386948] err = 1 [440700.386977] WARNING: CPU: 11 PID: 2733 at /build/linux-hwe-5.4-p6lk6L/linux-hwe-5.4-5.4.0/lib/errseq.c:74 errseq_set+0x5c/0x70 … [440700.397304] CPU: 11 PID: 2733 Comm: tar Tainted: G OE 5.4.0-70-generic #78~18.04.1-Ubuntu … [440700.397334] Call Trace: [440700.397346] __filemap_set_wb_err+0x1a/0x70 [440700.397419] cifs_writepages+0x9c7/0xb30 [cifs] [440700.397426] do_writepages+0x4b/0xe0 [440700.397444] __filemap_fdatawrite_range+0xcb/0x100 [440700.397455] filemap_write_and_wait+0x42/0xa0 [440700.397486] cifs_setattr+0x68b/0xf30 [cifs] [440700.397493] notify_change+0x358/0x4a0 [440700.397500] utimes_common+0xe9/0x1c0 [440700.397510] do_utimes+0xc5/0x150 [440700.397520] __x64_sys_utimensat+0x88/0xd0
description
在Linux内核中,已解决以下漏洞:cifs:从smb2_get_enc_key返回正确的错误代码如果错误渗透到备份中,则避免出现警告:[4440700.376476]cifs VFS:\otters.example.com crypt_message:无法获取加密密钥[4440700.3586947]—————[此处剪切]—————-[4440700.3686948]err=1[4440700.886977]警告:CPU:11 PID:2733 at/build/linux-hwe-5.4-p6lk6L/linux-hve-5.4-5.4.0/lib/errseq.c:74 errseq_set+0x5c/0x70。。。〔440700.397304〕CPU:11 PID:2733通讯:tar污染:G OE 5.4.0-70-generic#78~18.04.1-Ubuntu。。。[444000.397334]调用跟踪:[444000.97346]__filemap_set_wb_err+0x1a/0x70[444000.377419]cifs_writepages+0x9c7/0xb30[cifs][440700.397426]do_writepages+0x4b/0xe0[444000.3794444]__filemap_fdatawrite_range+0xcb/0x100[444000.3697455]filemap_write_and_wait+0x42/0xa0[4440700.397286]cifs_setattr+0x68b/0xf30[cifs][4440700.997493]通知_更改+0x358/0x4a0[444000.397500]实用程序_公用程序+0xe9/0x1c0[444000.397510]do_utimes+0xc5/0x150[444000.399520]__x64_sys_utimensa+0x88/0xd0
cvss | epss | percentile |
---|---|---|
None | 0.04% | 8.10% |
references
- https://git.kernel.org/stable/c/83728cbf366e334301091d5b808add468ab46b27
- https://git.kernel.org/stable/c/93f3339b22ba17e66f0808737467b70ba087eaec
- https://git.kernel.org/stable/c/aaa0faa5c28a91c362352d6b35dc3ed10df56fb0
- https://git.kernel.org/stable/c/b399c1a3ea0b9d10047ff266d65533df7f15532f
- https://git.kernel.org/stable/c/e486f8397f3f14a7cadc166138141fdb14379a54
- https://git.kernel.org/stable/c/e94851629c49c65b4fbb29a5725ddfd7988f8f20
- https://git.kernel.org/stable/c/f59a9242942fef0de7b926e438ba4eae65d4b4dd
CVE-2021-46961
description
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Do not enable irqs when handling spurious interrups We triggered the following error while running our 4.19 kernel with the pseudo-NMI patches backported to it: [ 14.816231] ————[ cut here ]———— [ 14.816231] kernel BUG at irq.c:99! [ 14.816232] Internal error: Oops - BUG: 0 [#1] SMP [ 14.816232] Process swapper/0 (pid: 0, stack limit = 0x(ptrval)) [ 14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.19.95.aarch64 #14 [ 14.816233] Hardware name: evb (DT) [ 14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO) [ 14.816234] pc : asm_nmi_enter+0x94/0x98 [ 14.816235] lr : asm_nmi_enter+0x18/0x98 [ 14.816235] sp : ffff000008003c50 [ 14.816235] pmr_save: 00000070 [ 14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0 [ 14.816238] x27: 0000000000000000 x26: ffff000008004000 [ 14.816239] x25: 00000000015e0000 x24: ffff8008fb916000 [ 14.816240] x23: 0000000020400005 x22: ffff0000080817cc [ 14.816241] x21: ffff000008003da0 x20: 0000000000000060 [ 14.816242] x19: 00000000000003ff x18: ffffffffffffffff [ 14.816243] x17: 0000000000000008 x16: 003d090000000000 [ 14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40 [ 14.816244] x13: ffff8008fff58b9d x12: 0000000000000000 [ 14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5 [ 14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f [ 14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e [ 14.816248] x5 : 0000000000000000 x4 : 0000000080000000 [ 14.816249] x3 : 0000000000000000 x2 : 0000000080000000 [ 14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0 [ 14.816251] Call trace: [ 14.816251] asm_nmi_enter+0x94/0x98 [ 14.816251] el1_irq+0x8c/0x180 (IRQ C) [ 14.816252] gic_handle_irq+0xbc/0x2e4 [ 14.816252] el1_irq+0xcc/0x180 (IRQ B) [ 14.816253] arch_timer_handler_virt+0x38/0x58 [ 14.816253] handle_percpu_devid_irq+0x90/0x240 [ 14.816253] generic_handle_irq+0x34/0x50 [ 14.816254] __handle_domain_irq+0x68/0xc0 [ 14.816254] gic_handle_irq+0xf8/0x2e4 [ 14.816255] el1_irq+0xcc/0x180 (IRQ A) [ 14.816255] arch_cpu_idle+0x34/0x1c8 [ 14.816255] default_idle_call+0x24/0x44 [ 14.816256] do_idle+0x1d0/0x2c8 [ 14.816256] cpu_startup_entry+0x28/0x30 [ 14.816256] rest_init+0xb8/0xc8 [ 14.816257] start_kernel+0x4c8/0x4f4 [ 14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000) [ 14.816258] Modules linked in: start_dp(O) smeth(O) [ 15.103092] —[ end trace 701753956cb14aa8 ]— [ 15.103093] Kernel panic - not syncing: Fatal exception in interrupt [ 15.103099] SMP: stopping secondary CPUs [ 15.103100] Kernel Offset: disabled [ 15.103100] CPU features: 0x36,a2400218 [ 15.103100] Memory Limit: none which is cause by a BUG_ON(in_nmi()) in nmi_enter(). From the call trace, we can find three interrupts (noted A, B, C above): interrupt (A) is preempted by (B), which is further interrupted by (C). Subsequent investigations show that (B) results in nmi_enter() being called, but that it actually is a spurious interrupt. Furthermore, interrupts are reenabled in the context of (B), and (C) fires with NMI priority. We end-up with a nested NMI situation, something we definitely do not want to (and cannot) handle. The bug here is that spurious interrupts should never result in any state change, and we should just return to the interrupted context. Moving the handling of spurious interrupts as early as possible in the GICv3 handler fixes this issue. [maz: rewrote commit message, corrected Fixes: tag]
description
在Linux内核中,以下漏洞已被解决:irqchip/gic-v3:在处理虚假的询问时不启用irqs我们在运行4.19内核时触发了以下错误,并将伪NMI修补程序向后移植到该内核:[14.816231]—————-[此处剪切]—————-[14.818231]内核BUG位于irq.c:99![14.816232]内部错误:Oops-BUG:0[#1]SMP[14.816234]进程交换程序/0[14.81235]sp:fff000008003c50[14.816235]pmr_save:00000070[14.816237]x29:ffff000008003c50 x28:ffff0000095f56c0[14.816238]x27:0000000000000000 x26:ffff00000800 4000[14.816239]x25:000000000 15e000 x24:ffff8008fb916000[14.816240]x23:00000000 20400005 x22:ffff0000080817cc[14.816241]x21:ff000008003da0 x20:00000000000000060[14.816242]x19:00000000000003ff x18:ffffffffff[14.816243]x17:000000000000000 8 x16:003d090000000000[14.816244]x15:ffff0000095ea6c8 x14:ffff8008fff5ab40[14.816224]x13:ffffff8008 fff58b9d x12:0000000000000000000000000[14.816245]x11:ffff000008c8a200 x10:0000000008e31fca5[14.816246]x9:ffff000008c8a208 x8:0000000000000000f[14.816247]x7:0000000000000004 x6:ffff8008fff58b9e[14.816248]x5:0000000000000000 x4:00000000 80000000[14.816249]x3:00000000 00000000 x2:00000000 000000[14.816250]x1:0000000000 120000 x0:ffffff0000095f56c0[14.816251]呼叫跟踪:[14.816256]asm_nmi_enter+0x94/0x98[14.816252]el1_irq+0x8c/0x180 8/0x58[14.816253]handle_percpu_devid_irq+0x90/0x240[14.816253]general_handle_irq+0x34/0x50[14.816254]__handle_domain_irq=0x68/0xc0[14.816250]gic_handle_irq+0xf8/0x2e4[14.816255]el1_irq+0xcc/0x180 _条目+0x28/0x30[14.816256]rest_init+0xf8/0xc8[14.816257]start_kernel+0x4c8/0x4f4[14.816257]代码:940587f1 d5384100 b9401001 36a7fd01(d4210000)[14.816258]链接在中的模块:start_dp(O)smeth(O)[15.103092]-[结束跟踪701753956cb14aa8]-[15.103093]内核死机-未同步:中断中的致命异常[15.103099]SMP:停止辅助CPU[15.103100]内核偏移:禁用[15.103100]CPU功能:0x36,a2400218[15.10310]内存限制:无,这是由nmi_enter()中的BUG_ON(in_nmi())引起的。从调用跟踪中,我们可以找到三个中断(上面提到的A、B、C):中断(A)被(B)抢占,后者被(C)进一步中断。随后的研究表明,(B)导致nmi_enter()被调用,但它实际上是一个伪中断。此外,中断在(B)和(C)的上下文中重新启用,并以NMI优先级触发。我们最终会出现嵌套的NMI情况,这是我们绝对不想(也不能)处理的。这里的错误是,虚假的中断永远不会导致任何状态更改,我们应该返回到中断的上下文。在GICv3处理程序中尽早移动虚假中断的处理可以修复此问题。[maz:重写提交消息,更正Fixes:tag]
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/3f72d3709f53af72835af7dc8b15ba61611a0e36
- https://git.kernel.org/stable/c/7be4db5c2b59fa77071c93ca4329876fb9777202
- https://git.kernel.org/stable/c/a97709f563a078e259bf0861cd259aa60332890a
- https://git.kernel.org/stable/c/e7ea8e46e3b777be26aa855fe07778c415f24926
- https://git.kernel.org/stable/c/ea817ac1014c04f47885532b55f5d0898deadfba
CVE-2021-46962
description
In the Linux kernel, the following vulnerability has been resolved: mmc: uniphier-sd: Fix a resource leak in the remove function A tmio_mmc_host_free() call is missing in the remove function, in order to balance a tmio_mmc_host_alloc() call in the probe. This is done in the error handling path of the probe, but not in the remove function. Add the missing call.
description
在Linux内核中,已解决以下漏洞:mmc:unihier sd:修复remove函数中的资源泄漏remove函数缺少tmio_mmc_host_free()调用,以平衡探测中的tmio_mmc_host_alloc()调用。这是在探测器的错误处理路径中完成的,但不在remove函数中完成。添加丢失的呼叫。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/0d8941b9b2d3e7b3481fdf43b1a6189d162175b7
- https://git.kernel.org/stable/c/25ac6ce65f1ab458982d15ec1caf441acd37106a
- https://git.kernel.org/stable/c/d6e7fda496978f2763413b5523557b38dc2bf6c2
- https://git.kernel.org/stable/c/e29c84857e2d51aa017ce04284b962742fb97d9e
- https://git.kernel.org/stable/c/ebe0f12cf4c044f812c6d17011531582f9ac8bb3
CVE-2021-46963
description
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash in qla2xxx_mqueuecommand() RIP: 0010:kmem_cache_free+0xfa/0x1b0 Call Trace: qla2xxx_mqueuecommand+0x2b5/0x2c0 [qla2xxx] scsi_queue_rq+0x5e2/0xa40 __blk_mq_try_issue_directly+0x128/0x1d0 blk_mq_request_issue_directly+0x4e/0xb0 Fix incorrect call to free srb in qla2xxx_mqueuecommand(), as srb is now allocated by upper layers. This fixes smatch warning of srb unintended free.
description
在Linux内核中,已解决以下漏洞:scsi:qla2xxx:修复qla2xxx_mqueuecommand()中的崩溃RIP:0010:kmem_cache_free+0xfa/0x1b0调用跟踪:qla2xxx_mqueuecommand+0x2b5/0x2c0[qla2xxx]scsi_queue_rq+0x5e2/0x40__blk_mq_try_sissue_directive+0x128/0x1d0 blk_MQL_request_issue_directly+0x4e/0xb0修复qla2xxx _mqueuecommand()中释放srb的错误调用,因为srb现在由上层分配。这修复了srb意外释放的smatch警告。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 8.10% |
references
- https://git.kernel.org/stable/c/6641df81ab799f28a5d564f860233dd26cca0d93
- https://git.kernel.org/stable/c/702cdaa2c6283c135ef16d52e0e4e3c1005aa538
- https://git.kernel.org/stable/c/77509a238547863040a42d57c72403f7d4c89a8f
- https://git.kernel.org/stable/c/80ef24175df2cba3860d0369d1c662b49ee2de56
- https://git.kernel.org/stable/c/a73208e3244127ef9f2cdf24e4adb947aaa32053
- https://git.kernel.org/stable/c/c5ab9b67d8b061de74e2ca51bf787ee599bd7f89
CVE-2021-46964
description
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Reserve extra IRQ vectors Commit a6dcfe08487e (“scsi: qla2xxx: Limit interrupt vectors to number of CPUs”) lowers the number of allocated MSI-X vectors to the number of CPUs. That breaks vector allocation assumptions in qla83xx_iospace_config(), qla24xx_enable_msix() and qla2x00_iospace_config(). Either of the functions computes maximum number of qpairs as: ha->max_qpairs = ha->msix_count - 1 (MB interrupt) - 1 (default response queue) - 1 (ATIO, in dual or pure target mode) max_qpairs is set to zero in case of two CPUs and initiator mode. The number is then used to allocate ha->queue_pair_map inside qla2x00_alloc_queues(). No allocation happens and ha->queue_pair_map is left NULL but the driver thinks there are queue pairs available. qla2xxx_queuecommand() tries to find a qpair in the map and crashes: if (ha->mqenable) { uint32_t tag; uint16_t hwq; struct qla_qpair *qpair = NULL; tag = blk_mq_unique_tag(cmd->request); hwq = blk_mq_unique_tag_to_hwq(tag); qpair = ha->queue_pair_map[hwq]; # <- HERE if (qpair) return qla2xxx_mqueuecommand(host, cmd, qpair); } 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] SMP PTI CPU: 0 PID: 72 Comm: kworker/u4:3 Tainted: G W 5.10.0-rc1+ #25 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Workqueue: scsi_wq_7 fc_scsi_scan_rport [scsi_transport_fc] RIP: 0010:qla2xxx_queuecommand+0x16b/0x3f0 [qla2xxx] Call Trace: scsi_queue_rq+0x58c/0xa60 blk_mq_dispatch_rq_list+0x2b7/0x6f0 ? __sbitmap_get_word+0x2a/0x80 __blk_mq_sched_dispatch_requests+0xb8/0x170 blk_mq_sched_dispatch_requests+0x2b/0x50 __blk_mq_run_hw_queue+0x49/0xb0 __blk_mq_delay_run_hw_queue+0xfb/0x150 blk_mq_sched_insert_request+0xbe/0x110 blk_execute_rq+0x45/0x70 __scsi_execute+0x10e/0x250 scsi_probe_and_add_lun+0x228/0xda0 __scsi_scan_target+0xf4/0x620 ? __pm_runtime_resume+0x4f/0x70 scsi_scan_target+0x100/0x110 fc_scsi_scan_rport+0xa1/0xb0 [scsi_transport_fc] process_one_work+0x1ea/0x3b0 worker_thread+0x28/0x3b0 ? process_one_work+0x3b0/0x3b0 kthread+0x112/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x22/0x30 The driver should allocate enough vectors to provide every CPU its own HW queue and still handle reserved (MB, RSP, ATIO) interrupts. The change fixes the crash on dual core VM and prevents unbalanced QP allocation where nr_hw_queues is two less than the number of CPUs.
description
在Linux内核中,已解决以下漏洞:scsi:qla2xxx:保留额外的IRQ矢量Commit a6dcfe08487e(“scsi:qla2xxx:将中断矢量限制为CPU数量”)将分配的MSI-X矢量数量降低为CPU数量。这打破了qla83xx_iospace_config()、qla24xx_enable_msix()和qla2x00.iospace_conconfig()中的向量分配假设。任一函数计算qpairs的最大数量为:ha->max_qpairs=ha->msix_count-1(MB中断)-1(默认响应队列)-1(ATIO,在双目标或纯目标模式下)在两个CPU和启动器模式的情况下,max_qpair设置为零。然后,该数字用于在qla2x00_alloc_queues()内分配ha->queue_pair_map。没有发生分配,ha->queue_pair_map为空,但驱动程序认为有可用的队列对。qla2xxx_queuecommand()试图在映射中找到一个qpair并崩溃:如果(ha->mqenable){uint32_t tag;uint16_t hwq;struct qla_qpair*qpair=NULL;tag=blk_mq_unique_tag(cmd->request);hwq=blk_mq_unique _tag_to_hwq(tag);qpair=ha->queue_pair_map[hwq];#<-HERE if(qpair)return qla2xxx_mqueuecommand(host,cmd,qpair);}BUG:内核NULL指针取消引用,地址:0000000000000000#PF:内核模式下的主管读取访问#PF:错误代码(0x0000)-不存在页面PGD 0 P4D 0错误:0000[#1]SMP PTI CPU:0 PID:72通信:kworker/u4:3损坏:G W 5.10.0-rc1+#25硬件名称:QEMU标准PC(Q35+ICH92009),BIOS 1.0.0-prebuilt.QEMU-project.org 04/01/2014工作队列:scsi_wq_7 fc_scsi_scan_rport[scsi_transport_fc]RIP:0010:qla2xxx_queuecommand+0x16b/0x3f0[qla2xxx]调用跟踪:scsi_queue_rq+0x58c/0xa60 blk_mq_dispatch_rq_list+0x2b7/0x6f0__sbitmap_get_word+0x2a/0x80 __blk_mq_sched_dispatch_requests+0xb8/0x170 blk_mq_schet_dispatch_rerequests+0x2b/0x50 __blk_Mqm_run_hw_queue+0x49/0xb0__blk_mq_delay_run_hw _queue+0xfb/0x150 blk_Mqsched_insert_request+0xfe/0x110 blk_execute_rq+0x45/0x70 __scsi_execute+0x10e/0x250 scsi_be_and_add_lun+0x228/0xda0 __scsi_scan_target+0xf4/0x620__pm_runtime_resume+0x4f/0x70 scsi_scan_target+0x100/0x110 fc_scsi_scan_rport+0xa1/0x20[scsi_transport_fc]process_one_work+0x1ea/0x3b0 worker_thread+0x28/0x3b0?process_one_work+0x3b0/0x3b0 k线程+0x112/0x130?kthread_park+0x80/0x80 ret_from_fork+0x22/0x30驱动程序应分配足够的向量,为每个CPU提供自己的硬件队列,并仍然处理保留的(MB、RSP、ATIO)中断。这一变化修复了双核虚拟机上的崩溃,并防止了不平衡的QP分配,其中nr_hw_queues比CPU数量少两个。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/0f86d66b38501e3ac66cf2d9f9f8ad6838bad0e6
- https://git.kernel.org/stable/c/4ecd42dec858b6632c5f024fe13e9ad6c30f2734
- https://git.kernel.org/stable/c/f02d4086a8f36a0e1aaebf559b54cf24a177a486
CVE-2021-46965
description
In the Linux kernel, the following vulnerability has been resolved: mtd: physmap: physmap-bt1-rom: Fix unintentional stack access Cast &data to (char *) in order to avoid unintentionally accessing the stack. Notice that data is of type u32, so any increment to &data will be in the order of 4-byte chunks, and this piece of code is actually intended to be a byte offset. Addresses-Coverity-ID: 1497765 (“Out-of-bounds access”)
description
在Linux内核中,已解决以下漏洞:mtd:physmap:physmap-bt1-rom:修复无意的堆栈访问将&data强制转换为(char*),以避免无意访问堆栈。请注意,数据的类型是u32,因此&data的任何增量都将按照4字节块的顺序进行,而这段代码实际上是一个字节偏移量。地址隐蔽ID:1497765(“越界访问”)
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/34ec706bf0b7c4ca249a729c1bcb91f706c7a7be
- https://git.kernel.org/stable/c/4d786870e3262ec098a3b4ed10b895176bc66ecb
- https://git.kernel.org/stable/c/4e4ebb827bf09311469ffd9d0c14ed40ed9747aa
- https://git.kernel.org/stable/c/683313993dbe1651c7aa00bb42a041d70e914925
CVE-2021-46966
description
In the Linux kernel, the following vulnerability has been resolved: ACPI: custom_method: fix potential use-after-free issue In cm_write(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cm_write() will still try to access it. Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function.
description
在Linux内核中,已解决以下漏洞:ACPI:custom_method:修复释放后的潜在使用问题在cm_write()中,buf总是在到达函数末尾时释放。如果请求的计数小于table.length,则分配的缓冲区将被释放,但随后对cm_write()的调用仍将尝试访问它。删除函数末尾的无条件kfree(buf),并在-EINVAL错误路径中将buf设置为NULL,以匹配函数的其余部分。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 10.59% |
references
- https://git.kernel.org/stable/c/1d53ca5d131074c925ce38361fb0376d3bf7e394
- https://git.kernel.org/stable/c/62dc2440ebb552aa0d7f635e1697e077d9d21203
- https://git.kernel.org/stable/c/72814a94c38a33239793f7622cec6ace1e540c4b
- https://git.kernel.org/stable/c/8b04d57f30caf76649d0567551589af9a66ca9be
- https://git.kernel.org/stable/c/90575d1d9311b753cf1718f4ce9061ddda7dfd23
- https://git.kernel.org/stable/c/a5b26a2e362f572d87e9fd35435680e557052a17
- https://git.kernel.org/stable/c/b7a5baaae212a686ceb812c32fceed79c03c0234
- https://git.kernel.org/stable/c/e483bb9a991bdae29a0caa4b3a6d002c968f94aa
- https://git.kernel.org/stable/c/f16737caf41fc06cfe6e49048becb09657074d4b
CVE-2021-46967
description
In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: fix vm_flags for virtqueue doorbell mapping The virtqueue doorbell is usually implemented via registeres but we dont provide the necessary vma->flags like VM_PFNMAP. This may cause several issues e.g when userspace tries to map the doorbell via vhost IOTLB, kernel may panic due to the page is not backed by page structure. This patch fixes this by setting the necessary vm_flags. With this patch, try to map doorbell via IOTLB will fail with bad address.
description
在Linux内核中,以下漏洞已被解决:vhost-vdpa:fix-vitqueue门铃映射的vm_flags virtqueue门铃通常通过寄存器实现,但我们不提供必要的vma->标志,如vm_PFNMAP。这可能会导致一些问题,例如,当用户空间试图通过vhostIOTLB映射门铃时,内核可能会因为页面没有页面结构支持而死机。此修补程序通过设置必要的vm_flags来修复此问题。使用此补丁,尝试通过IOTLB映射门铃将因地址错误而失败。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/3a3e0fad16d40a2aa68ddf7eea4acdf48b22dd44
- https://git.kernel.org/stable/c/3b8b6399666a29daa30b0bb3f5c9e3fc81c5a6a6
- https://git.kernel.org/stable/c/93dbbf20e3ffad14f04227a0b7105f6e6f0387ce
- https://git.kernel.org/stable/c/940230a5c31e2714722aee04c521a21f484b4df7
CVE-2021-46968
description
In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: fix zcard and zqueue hot-unplug memleak Tests with kvm and a kmemdebug kernel showed, that on hot unplug the zcard and zqueue structs for the unplugged card or queue are not properly freed because of a mismatch with get/put for the embedded kref counter. This fix now adjusts the handling of the kref counters. With init the kref counter starts with 1. This initial value needs to drop to zero with the unregister of the card or queue to trigger the release and free the object.
description
在Linux内核中,以下漏洞已被解决:s390/zcrypt:fix zcard和zqueue使用kvm和kmemdebug内核进行的热插拔内存泄漏测试显示,在热插拔时,由于与嵌入式kref计数器的get/put不匹配,未拔出的卡或队列的zcard或zqueue结构未正确释放。此修复程序现在调整kref计数器的处理。使用init,kref计数器以1开始。该初始值需要随着卡或队列的注销而降至零,以触发释放并释放对象。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/026499a9c2e002e621ad568d1378324ae97e5524
- https://git.kernel.org/stable/c/055a063a18bcd19b93709e3eac8078d6b2f04599
- https://git.kernel.org/stable/c/70fac8088cfad9f3b379c9082832b4d7532c16c2
- https://git.kernel.org/stable/c/971dc8706cee47393d393905d294ea47e39503d3
CVE-2021-46969
description
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: core: Fix invalid error returning in mhi_queue mhi_queue returns an error when the doorbell is not accessible in the current state. This can happen when the device is in non M0 state, like M3, and needs to be waken-up prior ringing the DB. This case is managed earlier by triggering an asynchronous M3 exit via controller resume/suspend callbacks, that in turn will cause M0 transition and DB update. So, since its not an error but just delaying of doorbell update, there is no reason to return an error. This also fixes a use after free error for skb case, indeed a caller queuing skb will try to free the skb if the queueing fails, but in that case queueing has been done.
description
在Linux内核中,已解决以下漏洞:bus:mhi:core:修复mhi_queue中返回的无效错误mhi_queue在当前状态下无法访问门铃时返回错误。当设备处于非M0状态(如M3),并且需要在振铃DB之前唤醒时,可能会发生这种情况。这种情况是通过控制器恢复/挂起回调触发异步M3退出来提前管理的,这反过来又会导致M0转换和DB更新。所以,由于这不是一个错误,只是门铃更新的延迟,所以没有理由返回错误。这也修复了skb的释放后使用错误。事实上,如果排队失败,排队的调用方skb将尝试释放skb,但在这种情况下,已经完成了排队。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://git.kernel.org/stable/c/0ecc1c70dcd32c0f081b173a1a5d89952686f271
- https://git.kernel.org/stable/c/a99b661c3187365f81026d89b1133a76cd2652b3
CVE-2021-46970
description
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: pci_generic: Remove WQ_MEM_RECLAIM flag from state workqueue A recent change created a dedicated workqueue for the state-change work with WQ_HIGHPRI (no strong reason for that) and WQ_MEM_RECLAIM flags, but the state-change work (mhi_pm_st_worker) does not guarantee forward progress under memory pressure, and will even wait on various memory allocations when e.g. creating devices, loading firmware, etc… The work is then not part of a memory reclaim path… Moreover, this causes a warning in check_flush_dependency() since we end up in code that flushes a non-reclaim workqueue: [ 40.969601] workqueue: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] is flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog [ 40.969612] WARNING: CPU: 4 PID: 158 at kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140 [ 40.969733] Call Trace: [ 40.969740] __flush_work+0x97/0x1d0 [ 40.969745] ? wake_up_process+0x15/0x20 [ 40.969749] ? insert_work+0x70/0x80 [ 40.969750] ? __queue_work+0x14a/0x3e0 [ 40.969753] flush_work+0x10/0x20 [ 40.969756] rollback_registered_many+0x1c9/0x510 [ 40.969759] unregister_netdevice_queue+0x94/0x120 [ 40.969761] unregister_netdev+0x1d/0x30 [ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net] [ 40.969770] mhi_driver_remove+0x124/0x250 [mhi] [ 40.969776] device_release_driver_internal+0xf0/0x1d0 [ 40.969778] device_release_driver+0x12/0x20 [ 40.969782] bus_remove_device+0xe1/0x150 [ 40.969786] device_del+0x17b/0x3e0 [ 40.969791] mhi_destroy_device+0x9a/0x100 [mhi] [ 40.969796] ? mhi_unmap_single_use_bb+0x50/0x50 [mhi] [ 40.969799] device_for_each_child+0x5e/0xa0 [ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi]
description
在Linux内核中,已解决以下漏洞:bus:mhi:pci_generic:从状态工作队列中删除WQ_MEM_RECLAIM标志最近的更改为使用WQ_HIGHPRI(没有充分的理由)和WQ_MEM _RECLAMP标志的状态更改工作创建了一个专用工作队列,但状态更改工作(mhi_pm_st_worker)不能保证在内存压力下向前推进,甚至会在创建设备、加载固件等时等待各种内存分配。因此,该工作不属于内存回收路径。。。此外,这会导致check_flush_dependency()中出现警告,因为我们最终会出现刷新非回收工作队列的代码:[40969601]工作队列:WQ_MEM_reclaim mhi_hiprio_WQ:mhi_pm_st_worker[mhi]正在刷新!WQ_MEM_RECLAIM events_highpri:flush_backlog[40969612]警告:CPU:4 PID:158在内核/工作队列。c:2607 check_flush_dependency+0x11c/0x140[40969733]调用跟踪:[409699740]__flush_work+0x97/0x1d0[409969745]?wake_up_process+0x15/0x20[40969749]?insert_work+0x70/0x80[40969750]__queue_work+0x14a/0x3e0[40969753]flush_work+0x10/0x20[40969756]rollback_registered_mounty+0x1c9/0x510[4096979]unregister_netdevice_queue+0x94/0x120[409699761]unregister-netdev+0x1d/0x30[40969765]mhi_net_remove+0x1a/0x40[mhi-net][40969770]mhi_driver_revove+0x124/0x250[mhi][4099776]device_release_driver_internal+0xf0/0x1d0[4099778]设备_租赁_驱动程序+0x12/0x20[40969782]总线_移动_设备+0xe1/0x150[409969786]设备_设备+0x17b/0x3e0[40969791]mhi_destroy_device+0x9a/0x100[mhi][40.96979696]?mhi_unmap_single_use_bb+0x50/0x50[mhi][40.969799]设备_for_each_child+0x5e/0xa0[40.969804]mhi_pm_st_worker+0x921/0xf50[mhi]
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/0fccbf0a3b690b162f53b13ed8bc442ea33437dc
- https://git.kernel.org/stable/c/abd1510c08a13c88d24b622a83c82e87ff1d3135
- https://git.kernel.org/stable/c/ed541cff35cbdb695f0c98ef506dd7218883fc07
CVE-2021-46971
description
In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix unconditional security_locked_down() call Currently, the lockdown state is queried unconditionally, even though its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in attr.sample_type. While that doesnt matter in case of the Lockdown LSM, it causes trouble with the SELinuxs lockdown hook implementation. SELinux implements the locked_down hook with a check whether the current tasks type has the corresponding “lockdown” class permission (“integrity” or “confidentiality”) allowed in the policy. This means that calling the hook when the access control decision would be ignored generates a bogus permission check and audit record. Fix this by checking sample_type first and only calling the hook when its result would be honored.
description
在Linux内核中,已解决以下漏洞:perf/core:修复无条件security_locked_down()调用当前,无条件查询锁定状态,即使只有在attr.SAMPLE_type中设置了perf_AMPLE_REGS_INTR位时才使用其结果。虽然这在Lockdown LSM的情况下并不重要,但它会导致SELinuxs锁定挂钩实现出现问题。SELinux通过检查当前任务类型是否具有策略中允许的相应“lockdown”类权限(“完整性”或“机密性”)来实现locked_down挂钩。这意味着当访问控制决策被忽略时调用钩子会生成一个伪造的权限检查和审计记录。通过首先检查sample_type并仅在满足其结果时调用hook来解决此问题。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/08ef1af4de5fe7de9c6d69f1e22e51b66e385d9b
- https://git.kernel.org/stable/c/4348d3b5027bc3ff6336368b6c60605d4ef8e1ce
- https://git.kernel.org/stable/c/b246759284d6a2bc5b6f1009caeeb3abce2ec9ff
- https://git.kernel.org/stable/c/c7b0208ee370b89d20486fae71cd9abb759819c1
- https://git.kernel.org/stable/c/f5809ca4c311b71bfaba6d13f4e39eab0557895e
CVE-2021-46972
description
In the Linux kernel, the following vulnerability has been resolved: ovl: fix leaked dentry Since commit 6815f479ca90 (“ovl: use only uppermetacopy state in ovl_lookup()”), overlayfs doesnt put temporary dentry when there is a metacopy error, which leads to dentry leaks when shutting down the related superblock: overlayfs: refusing to follow metacopy origin for (/file0) … BUG: Dentry (ptrval){i=3f33,n=file3} still in use (1) [unmount of overlay overlay] … WARNING: CPU: 1 PID: 432 at umount_check.cold+0x107/0x14d CPU: 1 PID: 432 Comm: unmount-overlay Not tainted 5.12.0-rc5 #1 … RIP: 0010:umount_check.cold+0x107/0x14d … Call Trace: d_walk+0x28c/0x950 ? dentry_lru_isolate+0x2b0/0x2b0 ? __kasan_slab_free+0x12/0x20 do_one_tree+0x33/0x60 shrink_dcache_for_umount+0x78/0x1d0 generic_shutdown_super+0x70/0x440 kill_anon_super+0x3e/0x70 deactivate_locked_super+0xc4/0x160 deactivate_super+0xfa/0x140 cleanup_mnt+0x22e/0x370 __cleanup_mnt+0x1a/0x30 task_work_run+0x139/0x210 do_exit+0xb0c/0x2820 ? __kasan_check_read+0x1d/0x30 ? find_held_lock+0x35/0x160 ? lock_release+0x1b6/0x660 ? mm_update_next_owner+0xa20/0xa20 ? reacquire_held_locks+0x3f0/0x3f0 ? __sanitizer_cov_trace_const_cmp4+0x22/0x30 do_group_exit+0x135/0x380 __do_sys_exit_group.isra.0+0x20/0x20 __x64_sys_exit_group+0x3c/0x50 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xae … VFS: Busy inodes after unmount of overlay. Self-destruct in 5 seconds. Have a nice day… This fix has been tested with a syzkaller reproducer.
description
在Linux内核中,已经解决了以下漏洞:ovl:修复泄漏的dentry自从提交6815f479ca90(“ovl:在ovl_lookup()中仅使用上元复制状态”)以来,overlayfs在出现元复制错误时不会放入临时dentry,这会导致在关闭相关的超级块时发生dentry泄漏:overlayfs:拒绝遵循(/file0)的元复制源。。。BUG:Dentry(____ ptrval____){i=3f3,n=file3}仍在使用中(1)[卸载覆盖层]。。。警告:CPU:1 PID:432在umont_check.cold+0x107/0x14d CPU:1 PID:332通信:卸载覆盖未受污染5.12.0-rc5#1。。。RIP:0010:umont_check.cold+0x107/0x14d。。。调用跟踪:d_walk+0x28c/0x950?dentry_lru_isolate+0x2b0/0x2b0__kasan_slab_free+0x12/0x20 do_one_tree+0x33/0x60 shrink_dcache_for_umont+0x78/0x1d0 general_shutdown_super+0x70/0x440 kill_anon_super+0x3e/0x70 deactivate_locked_super=0xc4/0x160 deactivate_super+0.xfa/0x140 cleanup_mnt+0x22e/0x370 __cleanup_mint+0x1a/0x30 task_work_run+0x139/0x210 do_exit+0x200c/0x2820__kasan_check_read+0x1d/0x30?find_held_lock+0x35/0x160?lock_release+0x1b6/0x660?mm_update_next_owner+0x20/0xa20?reaquire_held_locks+0x3f0/0x3f0__消毒器cov_trace_const_cmp4+0x22/0x30 do_group_exit+0x135/0x380 __do_sys_exit_group.isra.0+0x20/0x20 __x64_sys_exit_group+0x3c/0x50 do_syscall_64+0x45/0x70 entry_syscall_64_after_hwframe+0x44/0xae。。。VFS:卸载覆盖后,索引节点繁忙。5秒内自毁。祝您有个美好的一天。。。此修复程序已使用syzkaller复制机进行了测试。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/71d58457a8afc650da5d3292a7f7029317654d95
- https://git.kernel.org/stable/c/cf3e3330bc5719fa9d658e3e2f596bde89344a94
- https://git.kernel.org/stable/c/d587cfaef72b1b6f4b2774827123bce91f497cc8
- https://git.kernel.org/stable/c/eaab1d45cdb4bb0c846bd23c3d666d5b90af7b41
CVE-2021-46973
description
In the Linux kernel, the following vulnerability has been resolved: net: qrtr: Avoid potential use after free in MHI send It is possible that the MHI ul_callback will be invoked immediately following the queueing of the skb for transmission, leading to the callback decrementing the refcount of the associated sk and freeing the skb. As such the dereference of skb and the increment of the sk refcount must happen before the skb is queued, to avoid the skb to be used after free and potentially the sk to drop its last refcount..
description
在Linux内核中,已解决以下漏洞:net:qrtr:避免在MHI send中释放后使用MHI ul_callback可能会在skb排队等待传输后立即调用,导致回调减少相关sk的refcount并释放skb。因此,skb的取消引用和sk refcount的增加必须在skb排队之前发生,以避免在空闲之后使用skb,并可能导致sk丢弃其最后一个refcount。。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://git.kernel.org/stable/c/03c649dee8b1eb5600212a249542a70f47a5ab40
- https://git.kernel.org/stable/c/47a017f33943278570c072bc71681809b2567b3a
- https://git.kernel.org/stable/c/48ec949ac979b4b42d740f67b6177797af834f80
- https://git.kernel.org/stable/c/ea474054c2cc6e1284604b21361f475c7cc8c0a0
CVE-2021-46974
description
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix masking negation logic upon negative dst register The negation logic for the case where the off_reg is sitting in the dst register is not correct given then we cannot just invert the add to a sub or vice versa. As a fix, perform the final bitwise and-op unconditionally into AX from the off_reg, then move the pointer from the src to dst and finally use AX as the source for the original pointer arithmetic operation such that the inversion yields a correct result. The single non-AX mov in between is possible given constant blinding is retaining it as its not an immediate based operation.
description
在Linux内核中,已解决以下漏洞:bpf:修复负dst寄存器上的屏蔽否定逻辑off_reg位于dst寄存器中的情况下的否定逻辑不正确,因此我们不能将add反转为sub,反之亦然。作为修复方法,从off_reg无条件地对AX执行最后的逐位运算,然后将指针从src移动到dst,最后使用AX作为原始指针算术运算的源,以便反转产生正确的结果。如果持续盲法将其保留为非即时操作,则可能会出现介于两者之间的单个非AX mov。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 8.10% |
references
- https://git.kernel.org/stable/c/0e2dfdc74a7f4036127356d42ea59388f153f42c
- https://git.kernel.org/stable/c/2cfa537674cd1051a3b8111536d77d0558f33d5d
- https://git.kernel.org/stable/c/4d542ddb88fb2f39bf7f14caa2902f3e8d06f6ba
- https://git.kernel.org/stable/c/53e0db429b37a32b8fc706d0d90eb4583ad13848
- https://git.kernel.org/stable/c/6eba92a4d4be8feb4dc33976abac544fa99d6ecc
- https://git.kernel.org/stable/c/7cf64d8679ca1cb20cf57d6a88bfee79a0922a66
- https://git.kernel.org/stable/c/b9b34ddbe2076ade359cd5ce7537d5ed019e9807
CVE-2021-46975
description
In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: Make global sysctls readonly in non-init netns These sysctls point to global variables: - NF_SYSCTL_CT_MAX (&nf_conntrack_max) - NF_SYSCTL_CT_EXPECT_MAX (&nf_ct_expect_max) - NF_SYSCTL_CT_BUCKETS (&nf_conntrack_htable_size_user) Because their data pointers are not updated to point to per-netns structures, they must be marked read-only in a non-init_net ns. Otherwise, changes in any net namespace are reflected in (leaked into) all other net namespaces. This problem has existed since the introduction of net namespaces. The current logic marks them read-only only if the net namespace is owned by an unprivileged user (other than init_user_ns). Commit d0febd81ae77 (“netfilter: conntrack: re-visit sysctls in unprivileged namespaces”) “exposes all sysctls even if the namespace is unpriviliged.” Since we need to mark them readonly in any case, we can forego the unprivileged user check altogether.
description
在Linux内核中,已解决以下漏洞:netfilter:conntrack:使全局SYSCTL在非初始化网络中只读这些SYSCTL指向全局变量:-NF_SYSCTL_CT_MAX(&NF_conntrack_MAX)-NF_SYSCTCL_CT_EXPECT_MAX(&NF_CT_EXPECT_MAX)-NF_SYSCTL_CT_BUCKETS(&NF-conntrack_htable_size_user)因为它们的数据指针未更新为指向每个网络的结构,它们必须在非initnet ns中标记为只读。否则,任何网络名称空间的更改都会反映在(泄漏到)所有其他网络名称空间中。自从引入网络名称空间以来,这个问题就一直存在。只有当网络命名空间由非特权用户(而不是init_user_ns)所有时,当前逻辑才会将其标记为只读。Commit d0feebd81ae77(“netfilter:conntrack:re-visive sysctls in unprivileged namespaces”)“即使命名空间是非特权的,也会暴露所有sysctl。”由于在任何情况下我们都需要将它们标记为只读,因此我们可以完全放弃非特权用户检查。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 10.59% |
references
- https://git.kernel.org/stable/c/2671fa4dc0109d3fb581bc3078fdf17b5d9080f6
- https://git.kernel.org/stable/c/671c54ea8c7ff47bd88444f3fffb65bf9799ce43
- https://git.kernel.org/stable/c/68122479c128a929f8f7bdd951cfdc8dd0e75b8f
- https://git.kernel.org/stable/c/9b288479f7a901a14ce703938596438559d7df55
- https://git.kernel.org/stable/c/baea536cf51f8180ab993e374cb134b5edad25e2
- https://git.kernel.org/stable/c/d3598eb3915cc0c0d8cab42f4a6258ff44c4033e
- https://git.kernel.org/stable/c/da50f56e826e1db141693297afb99370ebc160dd
- https://git.kernel.org/stable/c/fbf85a34ce17c4cf0a37ee253f4c582bbfb8231b
CVE-2023-41506
description
An arbitrary file upload vulnerability in the Update/Edit Students Profile Picture function of Student Enrollment In PHP v1.0 allows attackers to execute arbitrary code via uploading a crafted PHP file.
description
PHP v1.0版学生注册的更新/编辑学生档案图片功能中存在任意文件上传漏洞,攻击者可以通过上传特制的PHP文件来执行任意代码。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2023-48678
description
Sensitive information disclosure due to insecure folder permissions. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 37391.
description
由于文件夹权限不安全而导致的敏感信息泄露。以下产品受到影响:版本37391之前的Acronis Cyber Protect 16(Linux、Windows)。
cvss | epss | percentile |
---|---|---|
5.5 MEDIUM | 0.04% | 6.87% |
references
CVE-2023-48679
description
Stored cross-site scripting (XSS) vulnerability due to missing origin validation in postMessage. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 37391.
description
由于postMessage中缺少来源验证,因此存在存储的跨站点脚本(XSS)漏洞。以下产品受到影响:版本37391之前的Acronis Cyber Protect 16(Linux、Windows)。
cvss | epss | percentile |
---|---|---|
3.1 LOW | 0.04% | 6.87% |
references
CVE-2023-48680
description
Sensitive information disclosure due to excessive collection of system information. The following products are affected: Acronis Cyber Protect 16 (macOS, Windows) before build 37391.
description
由于过度收集系统信息而导致的敏感信息泄露。以下产品受到影响:Acronis Cyber Protect 16(macOS,Windows)版本37391之前。
cvss | epss | percentile |
---|---|---|
3.3 LOW | 0.04% | 6.87% |
references
CVE-2023-48681
description
Self cross-site scripting (XSS) vulnerability in storage nodes search field. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 37391.
description
存储节点搜索字段中存在自跨站点脚本(XSS)漏洞。以下产品受到影响:版本37391之前的Acronis Cyber Protect 16(Linux、Windows)。
cvss | epss | percentile |
---|---|---|
1.9 LOW | 0.04% | 6.87% |
references
CVE-2023-48682
description
Stored cross-site scripting (XSS) vulnerability in unit name. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 37391.
description
单元名称中存在存储的跨站点脚本(XSS)漏洞。以下产品受到影响:版本37391之前的Acronis Cyber Protect 16(Linux、Windows)。
cvss | epss | percentile |
---|---|---|
6.1 MEDIUM | 0.04% | 6.87% |
references
CVE-2023-50379
description
Malicious code injection in Apache Ambari in prior to 2.7.8. Users are recommended to upgrade to version 2.7.8, which fixes this issue. Impact: A Cluster Operator can manipulate the request by adding a malicious code injection and gain a root over the cluster main host.
description
2.7.8之前的Apache Ambari中的恶意代码注入。建议用户升级到2.7.8版本,该版本修复了此问题。影响:集群操作员可以通过添加恶意代码注入来处理请求,并在集群主主机上获得根。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- http://www.openwall.com/lists/oss-security/2024/02/27/1
- https://lists.apache.org/thread/jglww6h6ngxpo1r6r5fx7ff7z29lnvv8
CVE-2023-50380
description
XML External Entity injection in apache ambari versions <= 2.7.7, Users are recommended to upgrade to version 2.7.8, which fixes this issue. More Details: Oozie Workflow Scheduler had a vulnerability that allowed for root-level file reading and privilege escalation from low-privilege users. The vulnerability was caused through lack of proper user input validation. This vulnerability is known as an XML External Entity (XXE) injection attack. Attackers can exploit XXE vulnerabilities to read arbitrary files on the server, including sensitive system files. In theory, it might be possible to use this to escalate privileges.
description
apache ambari版本<=2.7.7中的XML外部实体注入,建议用户升级到2.7.8版本,该版本修复了此问题。更多详细信息:Oozie Workflow Scheduler存在允许低权限用户读取根级文件和权限升级的漏洞。该漏洞是由于缺乏正确的用户输入验证而导致的。此漏洞被称为XML外部实体(XXE)注入攻击。攻击者可以利用XXE漏洞读取服务器上的任意文件,包括敏感系统文件。从理论上讲,可以利用这一点来提升特权。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- http://www.openwall.com/lists/oss-security/2024/02/27/6
- https://lists.apache.org/thread/qrt7mq7v7zyrh1qsh1gkg1m7clysvy32
CVE-2023-51518
description
Apache James prior to version 3.7.5 and 3.8.0 exposes a JMX endpoint on localhost subject to pre-authentication deserialisation of untrusted data. Given a deserialisation gadjet, this could be leveraged as part of an exploit chain that could result in privilege escalation. Note that by default JMX endpoint is only bound locally. We recommend users to: - Upgrade to a non-vulnerable Apache James version - Run Apache James isolated from other processes (docker - dedicated virtual machine) - If possible turn off JMX
description
版本3.7.5和3.8.0之前的Apache James在localhost上公开了一个JMX端点,该端点需要对不受信任的数据进行预身份验证取消序列化。考虑到一个取消序列化的gadjet,这可以作为可能导致特权升级的利用链的一部分。请注意,默认情况下,JMX端点仅在本地绑定。我们建议用户:-升级到不易受攻击的Apache James版本-运行与其他进程隔离的Apache James(docker-专用虚拟机)-如果可能,关闭JMX
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2023-51747
description
Apache James prior to versions 3.8.1 and 3.7.5 is vulnerable to SMTP smuggling. A lenient behaviour in line delimiter handling might create a difference of interpretation between the sender and the receiver which can be exploited by an attacker to forge an SMTP envelop, allowing for instance to bypass SPF checks. The patch implies enforcement of CRLF as a line delimiter as part of the DATA transaction. We recommend James users to upgrade to non vulnerable versions.
description
3.8.1和3.7.5版本之前的Apache James易受SMTP走私的攻击。行分隔符处理中的宽松行为可能会在发送方和接收方之间造成解释差异,攻击者可以利用这种差异伪造SMTP信封,例如绕过SPF检查。该补丁意味着将CRLF作为行分隔符强制执行,作为DATA事务的一部分。我们建议James用户升级到不易受攻击的版本。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- http://www.openwall.com/lists/oss-security/2024/02/27/4
- https://lists.apache.org/thread/rxkwbkh9vgbl9rzx1fkllyk3krhgydko
- https://postfix.org/smtp-smuggling.html
- https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
CVE-2023-5947
description
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2023-7247. Reason: This candidate is a duplicate of CVE-2023-7247. Notes: All CVE users should reference CVE-2023-7247 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.
description
拒绝不要使用此候选号码。咨询编号:CVE-2023-7247。原因:此候选者是CVE-2023-7247的副本。注:所有CVE用户应参考CVE-2023-7247,而不是此候选者。已删除此候选者中的所有参考文献和描述,以防止意外使用。
cvss | epss | percentile |
---|---|---|
None | None | None |
CVE-2023-5993
description
A flaw in the Windows Installer in Thales SafeNet Authentication Client prior to 10.8 R10 on Windows allows an attacker to escalate their privilege level via local access.
description
Windows 10.8 R10之前版本的Thales SafeNet Authentication Client中的Windows安装程序存在漏洞,攻击者可以通过本地访问升级其权限级别。
cvss | epss | percentile |
---|---|---|
7.8 HIGH | 0.04% | 6.87% |
references
CVE-2023-6584
description
The WP JobSearch WordPress plugin before 2.3.4 does not prevent attackers from logging-in as any users with the only knowledge of that users email address.
description
2.3.4之前的WP JobSearch WordPress插件不能阻止攻击者以只知道该用户电子邮件地址的任何用户身份登录。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2023-6585
description
The WP JobSearch WordPress plugin before 2.3.4 does not validate files to be uploaded, which could allow unauthenticated attackers to upload arbitrary files such as PHP on the server
description
2.3.4之前的WP JobSearch WordPress插件不验证要上传的文件,这可能允许未经验证的攻击者在服务器上上传任意文件,如PHP
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2023-7016
description
A flaw in Thales SafeNet Authentication Client prior to 10.8 R10 on Windows allows an attacker to execute code at a SYSTEM level via local access.
description
Windows 10.8 R10之前版本的泰雷兹SafeNet身份验证客户端存在漏洞,攻击者可通过本地访问在SYSTEM级别执行代码。
cvss | epss | percentile |
---|---|---|
7.8 HIGH | 0.04% | 6.87% |
references
CVE-2023-7033
description
Insufficient Resource Pool vulnerability in Ethernet function of Mitsubishi Electric Corporation MELSEC iQ-F Series CPU modules allows a remote attacker to cause a temporary Denial of Service condition for a certain period of time in Ethernet communication of the products by performing TCP SYN Flood attack.
description
三菱电机公司MELSEC iQ-F系列CPU模块的以太网功能中存在资源池不足漏洞,远程攻击者可以通过执行TCP SYN Flood攻击,在产品的以太网通信中造成一定时间内的临时拒绝服务条件。
cvss | epss | percentile |
---|---|---|
5.3 MEDIUM | 0.04% | 12.26% |
references
- https://jvn.jp/vu/JVNVU96145466/index.html
- https://www.cisa.gov/news-events/ics-advisories/icsa-24-058-01
- https://www.mitsubishielectric.com/en/psirt/vulnerability/pdf/2023-023_en.pdf
CVE-2023-7115
description
The Page Builder: Pagelayer WordPress plugin before 1.8.1 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup)
description
页面生成器:1.8.1之前的Pagelayer WordPress插件不会净化和逃脱其某些设置,这可能允许管理员等高权限用户执行存储跨站点脚本攻击,即使在不允许使用unstered.html功能的情况下(例如在多站点设置中)
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2023-7165
description
The JetBackup WordPress plugin before 2.0.9.9 doesnt use index files to prevent public directory listing of sensitive directories in certain configurations, which allows malicious actors to leak backup files.
description
2.0.9.9之前的JetBackup WordPress插件不使用索引文件来阻止某些配置中敏感目录的公共目录列表,这允许恶意行为者泄露备份文件。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2023-7167
description
The Persian Fonts WordPress plugin through 1.6 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup).
description
波斯字体WordPress插件1.6版不会对其某些设置进行消毒和转义,这可能会允许管理员等高权限用户执行存储跨站点脚本攻击,即使不允许使用unstered.html功能(例如在多站点设置中)。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2023-7198
description
The WP Dashboard Notes WordPress plugin before 1.0.11 is vulnerable to Insecure Direct Object References (IDOR) in post_id= parameter. Authenticated users are able to delete private notes associated with different user accounts. This poses a significant security risk as it violates the principle of least privilege and compromises the integrity and privacy of user data.
description
1.0.11之前的WP Dashboard Notes WordPress插件在post_id=parameter中易受不安全直接对象引用(IDOR)的攻击。经过身份验证的用户可以删除与不同用户帐户关联的私人笔记。这构成了重大的安全风险,因为它违反了最小特权原则,并损害了用户数据的完整性和隐私。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2023-7202
description
The Fatal Error Notify WordPress plugin before 1.5.3 does not have authorisation and CSRF checks in its test_error AJAX action, allowing any authenticated users, such as subscriber to call it and spam the admin email address with error messages. The issue is also exploitable via CSRF
description
1.5.3之前的致命错误通知WordPress插件在其test_Error AJAX操作中没有授权和CSRF检查,允许任何经过身份验证的用户(如订阅者)呼叫它并向管理员电子邮件地址发送带有错误消息的垃圾邮件。该问题也可通过CSRF加以利用
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://research.cleantalk.org/cve-2023-7202-fatal-error-notify-error-email-sending-csrf/
- https://wpscan.com/vulnerability/d923ba5b-1c20-40ee-ac69-cd0bb65b375a/
CVE-2023-7203
description
The Smart Forms WordPress plugin before 2.6.87 does not have authorisation in various AJAX actions, which could allow users with a role as low as subscriber to call them and perform unauthorised actions such as deleting entries. The plugin also lacks CSRF checks in some places which could allow attackers to make logged in users perform unwanted actions via CSRF attacks such as deleting entries.
description
2.6.87之前的智能表单WordPress插件在各种AJAX操作中没有授权,这可能允许角色低至订阅者的用户呼叫他们并执行未经授权的操作,如删除条目。该插件在某些地方也缺乏CSRF检查,这可能允许攻击者通过CSRF攻击(如删除条目)让登录用户执行不必要的操作。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-0197
description
A flaw in the installer for Thales SafeNet Sentinel HASP LDK prior to 9.16 on Windows allows an attacker to escalate their privilege level via local access.
description
Windows上9.16之前版本的Thales SafeNet Sentinel HASP LDK的安装程序中存在漏洞,攻击者可以通过本地访问升级其权限级别。
cvss | epss | percentile |
---|---|---|
7.8 HIGH | 0.04% | 6.87% |
references
CVE-2024-0551
description
Enable exports of the database and associated exported information of the system via the default user role. The attacked would have to have been granted access to the system prior to the attack. It is worth noting that the deterministic nature of the export name is lower risk as the UI for exporting would start the download at the same time, which once downloaded - deletes the export from the system. The endpoint for exporting should simply be patched to a higher privilege level.
description
启用通过默认用户角色导出数据库和系统的相关导出信息。被攻击者必须在攻击之前被授予访问系统的权限。值得注意的是,导出名称的确定性降低了风险,因为用于导出的UI将同时启动下载,下载后将从系统中删除导出。导出的端点应该简单地修补到更高的特权级别。
cvss | epss | percentile |
---|---|---|
7.1 HIGH | 0.04% | 6.87% |
references
- https://github.com/mintplex-labs/anything-llm/commit/7aaa4b38e7112a6cd879c1238310c56b1844c6d8
- https://huntr.com/bounties/f114c787-ab5f-4f83-afa5-c000435efb78
CVE-2024-0759
description
Should an instance of AnythingLLM be hosted on an internal network and the attacked be explicitly granted a permission level of manager or admin, they could link-scrape internally resolving IPs of other services that are on the same network as AnythingLLM. This would require the attacker also be able to guess these internal IPs as /*
ranging is not possible, but could be brute forced. There is a duty of care that other services on the same network would not be fully open and accessible via a simple CuRL with zero authentication as it is not possible to set headers or access via the link collector.
description
如果AnythingLLM的实例托管在内部网络上,并且被攻击者被明确授予管理员或管理员的权限级别,他们可以在内部链接刮取与AnythingLLC在同一网络上的其他服务的解析IP。这将要求攻击者也能够猜测这些内部IP,因为“/*”测距是不可能的,但可能是暴力强制的。需要注意的是,同一网络上的其他服务不会完全开放,也不会通过零认证的简单CuRL进行访问,因为不可能通过链路收集器设置报头或进行访问。
cvss | epss | percentile |
---|---|---|
9.6 CRITICAL | 0.04% | 6.87% |
references
- https://github.com/mintplex-labs/anything-llm/commit/0db6c3b2aa1787a7054ffdaba975474f122c20eb
- https://huntr.com/bounties/9a978edd-ac94-41fc-8e3e-c35441bdd12b
CVE-2024-0763
description
Any user can delete an arbitrary folder (recursively) on a remote server due to bad input sanitization leading to path traversal. The attacker would need access to the server at some privilege level since this endpoint is protected and requires authorization.
description
任何用户都可以(递归地)删除远程服务器上的任意文件夹,因为错误的输入净化会导致路径遍历。攻击者需要以某种特权级别访问服务器,因为此端点受到保护并且需要授权。
cvss | epss | percentile |
---|---|---|
8.1 HIGH | 0.04% | 6.87% |
references
- https://github.com/mintplex-labs/anything-llm/commit/8a7324d0e77a15186e1ad5e5119fca4fb224c39c
- https://huntr.com/bounties/25a2f487-5a9c-4c7f-a2d3-b0527db73ea5
CVE-2024-0819
description
Improper initialization of default settings in TeamViewer Remote Client prior version 15.51.5 for Windows, Linux and macOS, allow a low privileged user to elevate privileges by changing the personal password setting and establishing a remote connection to a logged-in admin account.
description
TeamViewer Remote Client 15.51.5之前版本(适用于Windows、Linux和macOS)中的默认设置初始化不当,允许低特权用户通过更改个人密码设置和建立与登录管理员帐户的远程连接来提升权限。
cvss | epss | percentile |
---|---|---|
7.3 HIGH | 0.04% | 6.87% |
references
CVE-2024-0855
description
The Spiffy Calendar WordPress plugin before 4.9.9 doesnt check the event_author parameter, and allows any user to alter it when creating an event, leading to deceiving users/admins that a page was created by a Contributor+.
description
4.9.9之前的Spiffy Calendar WordPress插件不检查event_author参数,并允许任何用户在创建事件时对其进行更改,从而欺骗用户/管理员页面是由Contributor+创建的。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-1106
description
The Shariff Wrapper WordPress plugin before 4.6.10 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup)
description
4.6.10之前的Shariff Wrapper WordPress插件不会对其某些设置进行消毒和转义,这可能会允许管理员等高权限用户执行存储跨站点脚本攻击,即使在不允许使用unstered.html功能的情况下(例如在多站点设置中)
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-1323
description
The Orbit Fox by ThemeIsle plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugins Post Type Grid Widget Title in all versions up to, and including, 2.10.30 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
description
WordPress的Orbit Fox by ThemeIsle插件在2.10.30之前(包括2.10.30)的所有版本中都容易受到通过插件Post-Type Grid Widget Title存储的跨站点脚本的攻击,原因是用户提供的属性的输入净化和输出转义不足。这使得具有贡献者级别及以上权限的经过身份验证的攻击者有可能在页面中注入任意web脚本,这些脚本将在用户访问注入的页面时执行。
cvss | epss | percentile |
---|---|---|
6.4 MEDIUM | 0.04% | 12.26% |
references
- https://plugins.trac.wordpress.org/changeset/3040304/themeisle-companion/tags/2.10.32/vendor/codeinwp/elementor-extra-widgets/class-elementor-extra-widgets.php
- https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=3038451%40themeisle-companion&new=3038451%40themeisle-companion&sfp_email=&sfph_mail=
- https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=3040304%40themeisle-companion&new=3040304%40themeisle-companion&sfp_email=&sfph_mail=
- https://www.wordfence.com/threat-intel/vulnerabilities/id/0241a9fc-ce42-4a97-9f33-f07cf53c0f52?source=cve
CVE-2024-1403
description
In OpenEdge Authentication Gateway and AdminServer prior to 11.7.19, 12.2.14, 12.8.1 on all platforms supported by the OpenEdge product, an authentication bypass vulnerability has been identified. The vulnerability is a bypass to authentication based on a failure to properly handle username and password. Certain unexpected content passed into the credentials can lead to unauthorized access without proper authentication.
description
在OpenEdge产品支持的所有平台上,在11.7.19、12.2.14和12.8.1之前的OpenEdge身份验证网关和AdminServer中,已发现身份验证绕过漏洞。该漏洞是基于未能正确处理用户名和密码而绕过身份验证的漏洞。传递到凭据中的某些意外内容可能导致在没有正确身份验证的情况下进行未经授权的访问。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
CVE-2024-1423
description
** REJECT ** Accidental Request
description
拒绝意外请求
cvss | epss | percentile |
---|---|---|
None | None | None |
CVE-2024-1649
description
The Categorify plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the categorifyAjaxDeleteCategory function in all versions up to, and including, 1.0.7.4. This makes it possible for authenticated attackers, with subscriber-level access and above, to delete categories.
description
WordPress的Categorify插件很容易受到未经授权的数据修改,因为在1.0.7.4之前(包括1.0.7.4)的所有版本中,都缺少对categorifyAjaxDeleteCategory函数的功能检查。这使得具有订户级及以上访问权限的经过身份验证的攻击者有可能删除类别。
cvss | epss | percentile |
---|---|---|
4.3 MEDIUM | 0.04% | 6.87% |
references
- https://plugins.trac.wordpress.org/changeset/3034410/categorify
- https://www.wordfence.com/threat-intel/vulnerabilities/id/c63ddc62-a4f1-4da4-a65e-4573369d6c30?source=cve
CVE-2024-1650
description
The Categorify plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the categorifyAjaxRenameCategory function in all versions up to, and including, 1.0.7.4. This makes it possible for authenticated attackers, with subscriber-level access and above, to rename categories.
description
WordPress的Categorify插件很容易受到未经授权的数据修改,因为在1.0.7.4之前(包括1.0.7.4)的所有版本中,都缺少对categorifyAjaxRenameCategory函数的功能检查。这使得具有订户级及以上访问权限的经过身份验证的攻击者有可能重命名类别。
cvss | epss | percentile |
---|---|---|
4.3 MEDIUM | 0.04% | 6.87% |
references
- https://plugins.trac.wordpress.org/changeset/3034410/categorify
- https://www.wordfence.com/threat-intel/vulnerabilities/id/f9a3dc87-5309-41fe-bfc3-60b5878b6c57?source=cve
CVE-2024-1652
description
The Categorify plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the categorifyAjaxClearCategory function in all versions up to, and including, 1.0.7.4. This makes it possible for authenticated attackers, with subscriber-level access and above, to clear categories.
description
WordPress的Categorify插件很容易受到未经授权的数据修改,因为在1.0.7.4之前(包括1.0.7.4)的所有版本中,都缺少对categorifyAjaxClearCategory功能的功能检查。这使得具有订户级及以上访问权限的经过身份验证的攻击者有可能清除类别。
cvss | epss | percentile |
---|---|---|
4.3 MEDIUM | 0.04% | 6.87% |
references
- https://plugins.trac.wordpress.org/changeset/3034410/categorify
- https://www.wordfence.com/threat-intel/vulnerabilities/id/acccc6ae-553d-4ed5-8ba9-06a9061d725c?source=cve
CVE-2024-1653
description
The Categorify plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the categorifyAjaxUpdateFolderPosition in all versions up to, and including, 1.0.7.4. This makes it possible for authenticated attackers, with subscriber-level access and above, to update the folder position of categories as well as update the metadata of other taxonomies.
description
WordPress的Categorify插件很容易受到未经授权的数据修改,因为在1.0.7.4之前(包括1.0.7.4)的所有版本中,都缺少对categorifyAjaxUpdateFolderPosition的功能检查。这使得具有订阅服务器级及以上访问权限的经过身份验证的攻击者有可能更新类别的文件夹位置以及更新其他分类的元数据。
cvss | epss | percentile |
---|---|---|
4.3 MEDIUM | 0.04% | 6.87% |
references
- https://plugins.trac.wordpress.org/changeset/3034410/categorify
- https://www.wordfence.com/threat-intel/vulnerabilities/id/45badd20-1ba8-44be-8a7c-2ce21261e208?source=cve
CVE-2024-1686
description
The Thank You Page Customizer for WooCommerce – Increase Your Sales plugin for WordPress is vulnerable to missing authorization e in all versions up to, and including, 1.1.2 via the apply_layout function due to a missing capability check. This makes it possible for authenticated attackers, with subscriber-level access and above, to retrieve arbitrary order data which may contain PII.
description
WooCommerce的感谢页面自定义程序–;WordPress的“增加你的销售额”插件在1.1.2之前(包括1.1.2)的所有版本中都容易因缺少功能检查而通过apply_layout功能丢失授权e。这使得具有订户级及以上访问权限的经过身份验证的攻击者有可能检索可能包含PII的任意顺序数据。
cvss | epss | percentile |
---|---|---|
5.3 MEDIUM | 0.04% | 6.87% |
references
- https://plugins.trac.wordpress.org/changeset/3041096/woo-thank-you-page-customizer/trunk/frontend/frontend.php
- https://www.wordfence.com/threat-intel/vulnerabilities/id/2e7ebc0c-6936-4632-a602-7131c7d8bd6a?source=cve
CVE-2024-1687
description
The Thank You Page Customizer for WooCommerce – Increase Your Sales plugin for WordPress is vulnerable to unauthorized execution of shortcodes due to a missing capability check on the get_text_editor_content() function in all versions up to, and including, 1.1.2. This makes it possible for authenticated attackers, with subscriber-level access and above, to execute arbitrary shortcodes.
description
WooCommerce的感谢页面自定义程序–;在1.1.2之前(包括1.1.2)的所有版本中,由于get_text_editor_content()函数缺少功能检查,WordPress的“增加您的销售额”插件很容易受到未经授权执行短代码的攻击。这使得具有订户级及以上访问权限的经过身份验证的攻击者有可能执行任意短代码。
cvss | epss | percentile |
---|---|---|
5.4 MEDIUM | 0.04% | 6.87% |
references
- https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=3041096%40woo-thank-you-page-customizer&new=3041096%40woo-thank-you-page-customizer&sfp_email=&sfph_mail=
- https://www.wordfence.com/threat-intel/vulnerabilities/id/310afe02-3a51-4633-b359-65ae58d0c032?source=cve
CVE-2024-1698
description
The NotificationX – Best FOMO, Social Proof, WooCommerce Sales Popup & Notification Bar Plugin With Elementor plugin for WordPress is vulnerable to SQL Injection via the type parameter in all versions up to, and including, 2.8.2 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.
description
NotificationX–;Best FOMO,Social Proof,WooCommerce Sales Popup&Notification Bar Plugin With Elementor Plugin for WordPress在2.8.2之前(包括2.8.2)的所有版本中都容易通过类型参数受到SQL注入的攻击,这是由于用户提供的参数转义不足,以及对现有SQL查询准备不足。这使得未经身份验证的攻击者有可能将其他SQL查询附加到现有查询中,这些查询可用于从数据库中提取敏感信息。
cvss | epss | percentile |
---|---|---|
9.8 CRITICAL | 0.04% | 12.26% |
references
- https://plugins.trac.wordpress.org/changeset/3040809/notificationx/trunk/includes/Core/Database.php
- https://plugins.trac.wordpress.org/changeset/3040809/notificationx/trunk/includes/Core/Rest/Analytics.php
- https://www.wordfence.com/threat-intel/vulnerabilities/id/e110ea99-e2fa-4558-bcf3-942a35af0b91?source=cve
CVE-2024-1722
description
A flaw was found in Keycloak. In certain conditions, this issue may allow a remote unauthenticated attacker to block other accounts from logging in.
description
在钥匙斗篷中发现了一个缺陷。在某些情况下,此问题可能允许未经身份验证的远程攻击者阻止其他帐户登录。
cvss | epss | percentile |
---|---|---|
3.7 LOW | 0.04% | 6.87% |
references
- https://access.redhat.com/security/cve/CVE-2024-1722
- https://bugzilla.redhat.com/show_bug.cgi?id=2265389
CVE-2024-1864
description
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2023-2813. Reason: This candidate is a duplicate of CVE-2023-2813. Notes: All CVE users should reference CVE-2023-2813 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.
description
拒绝不要使用此候选号码。咨询编号:CVE-2023-2813。原因:此候选者是CVE-2023-2813的副本。注:所有CVE用户应参考CVE-2023-2813,而不是此候选者。已删除此候选者中的所有参考文献和描述,以防止意外使用。
cvss | epss | percentile |
---|---|---|
None | None | None |
CVE-2024-1865
description
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2023-2813. Reason: This candidate is a duplicate of CVE-2023-2813. Notes: All CVE users should reference CVE-2023-2813 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.
description
拒绝不要使用此候选号码。咨询编号:CVE-2023-2813。原因:此候选者是CVE-2023-2813的副本。注:所有CVE用户应参考CVE-2023-2813,而不是此候选者。已删除此候选者中的所有参考文献和描述,以防止意外使用。
cvss | epss | percentile |
---|---|---|
None | None | None |
CVE-2024-1866
description
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2023-2813. Reason: This candidate is a duplicate of CVE-2023-2813. Notes: All CVE users should reference CVE-2023-2813 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.
description
拒绝不要使用此候选号码。咨询编号:CVE-2023-2813。原因:此候选者是CVE-2023-2813的副本。注:所有CVE用户应参考CVE-2023-2813,而不是此候选者。已删除此候选者中的所有参考文献和描述,以防止意外使用。
cvss | epss | percentile |
---|---|---|
None | None | None |
CVE-2024-1906
description
The Categorify plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.0.7.4. This is due to missing or incorrect nonce validation on the categorifyAjaxAddCategory function. This makes it possible for unauthenticated attackers to add categories via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
description
WordPress的分类插件在1.0.7.4之前(包括1.0.7.4)的所有版本中都容易受到跨站点请求伪造的攻击。这是由于categorifyAjaxAddCategory函数的nonce验证缺失或不正确。这使得未经身份验证的攻击者有可能通过伪造的请求添加类别,他们可以诱骗网站管理员执行诸如点击链接之类的操作。
cvss | epss | percentile |
---|---|---|
4.3 MEDIUM | 0.04% | 6.87% |
references
- https://plugins.trac.wordpress.org/changeset/3034410/categorify
- https://www.wordfence.com/threat-intel/vulnerabilities/id/78422a30-bdc6-4e7c-a018-c3dc4b4be6a0?source=cve
CVE-2024-1907
description
The Categorify plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.0.7.4. This is due to missing or incorrect nonce validation on the categorifyAjaxDeleteCategory function. This makes it possible for unauthenticated attackers to delete categories via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
description
WordPress的分类插件在1.0.7.4之前(包括1.0.7.4)的所有版本中都容易受到跨站点请求伪造的攻击。这是由于categorifyAjaxDeleteCategory函数的nonce验证缺失或不正确。这使得未经身份验证的攻击者有可能通过伪造的请求删除类别。他们可以诱使网站管理员执行诸如点击链接之类的操作。
cvss | epss | percentile |
---|---|---|
4.3 MEDIUM | 0.04% | 6.87% |
references
- https://plugins.trac.wordpress.org/changeset/3034410/categorify
- https://www.wordfence.com/threat-intel/vulnerabilities/id/08c79118-9dad-44fd-b683-7950276d3808?source=cve
CVE-2024-1909
description
The Categorify plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.0.7.4. This is due to missing or incorrect nonce validation on the categorifyAjaxRenameCategory function. This makes it possible for unauthenticated attackers to rename categories via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
description
WordPress的分类插件在1.0.7.4之前(包括1.0.7.4)的所有版本中都容易受到跨站点请求伪造的攻击。这是由于categorifyAjaxRenameCategory函数的nonce验证缺失或不正确。这使得未经身份验证的攻击者有可能通过伪造的请求重命名类别。他们可以诱使网站管理员执行诸如单击链接之类的操作。
cvss | epss | percentile |
---|---|---|
4.3 MEDIUM | 0.04% | 6.87% |
references
- https://plugins.trac.wordpress.org/changeset/3034410/categorify
- https://www.wordfence.com/threat-intel/vulnerabilities/id/58b29729-e9c3-4d57-affd-6142dfa8cc6f?source=cve
CVE-2024-1910
description
The Categorify plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.0.7.4. This is due to missing or incorrect nonce validation on the categorifyAjaxClearCategory function. This makes it possible for unauthenticated attackers to clear categories via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
description
WordPress的分类插件在1.0.7.4之前(包括1.0.7.4)的所有版本中都容易受到跨站点请求伪造的攻击。这是由于categorifyAjaxClearCategory函数的nonce验证缺失或不正确。这使得未经身份验证的攻击者有可能通过伪造的请求清除类别。他们可以诱使网站管理员执行诸如点击链接之类的操作。
cvss | epss | percentile |
---|---|---|
4.3 MEDIUM | 0.04% | 6.87% |
references
- https://plugins.trac.wordpress.org/changeset/3034410/categorify
- https://www.wordfence.com/threat-intel/vulnerabilities/id/b1c2712d-0865-4759-98da-1e11a26f2466?source=cve
CVE-2024-1912
description
The Categorify plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.0.7.4. This is due to missing or incorrect nonce validation on the categorifyAjaxUpdateFolderPosition function. This makes it possible for unauthenticated attackers to update the folder position of categories as well as update the metadata of other taxonomies via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
description
WordPress的分类插件在1.0.7.4之前(包括1.0.7.4)的所有版本中都容易受到跨站点请求伪造的攻击。这是由于categorifyAjaxUpdateFolderPosition函数的nonce验证缺失或不正确。这使得未经身份验证的攻击者有可能通过伪造的请求更新类别的文件夹位置以及更新其他分类的元数据。他们可以诱使网站管理员执行诸如单击链接之类的操作。
cvss | epss | percentile |
---|---|---|
4.3 MEDIUM | 0.04% | 6.87% |
references
- https://plugins.trac.wordpress.org/changeset/3034410/categorify
- https://www.wordfence.com/threat-intel/vulnerabilities/id/6ca28c91-f75e-4691-91cf-459cc9da5ad8?source=cve
CVE-2024-1918
description
A vulnerability has been found in Beijing Baichuo Smart S42 Management Platform up to 20240219 and classified as critical. Affected by this vulnerability is an unknown functionality of the file /useratte/userattestation.php. The manipulation of the argument hidwel leads to unrestricted upload. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-254839. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
description
截至20240219年,在北京百厨智能S42管理平台中发现了一个漏洞,该漏洞被列为关键漏洞。受此漏洞影响的是文件/useratte/usercertification.php的一个未知功能。参数hidwel的操作会导致不受限制的上传。可以远程发起攻击。该漏洞已向公众公开,并可能被利用。此漏洞的相关标识符为VDB-254839。注:我们很早就联系了供应商,但没有以任何方式作出回应。
cvss | epss | percentile |
---|---|---|
4.7 MEDIUM | 0.04% | 12.26% |
references
- https://github.com/Echosssy/CVE/blob/main/%E5%85%B3%E4%BA%8ESmart%20S42%E7%AE%A1%E7%90%86%E5%B9%B3%E5%8F%B0%E5%AD%98%E5%9C%A8%E6%96%87%E4%BB%B6%E4%B8%8A%E4%BC%A0%E6%BC%8F%E6%B4%9E%E7%9A%84%E6%83%85%E5%86%B5%E9%80%9A%E6%8A%A5-userattestation.php.docx
- https://vuldb.com/?ctiid.254839
- https://vuldb.com/?id.254839
CVE-2024-1919
description
A vulnerability classified as problematic was found in SourceCodester Online Job Portal 1.0. This vulnerability affects unknown code of the file /Employer/ManageWalkin.php of the component Manage Walkin Page. The manipulation of the argument Job Title leads to cross site scripting. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. VDB-254854 is the identifier assigned to this vulnerability.
description
在SourceCodester Online Job Portal 1.0中发现一个被归类为有问题的漏洞。此漏洞影响组件Manage Walkin Page的文件/EEmployer/ManageWalkin.php的未知代码。对参数Job Title的操作会导致跨站点脚本编写。可以远程发起攻击。该漏洞已向公众公开,并可能被利用。VDB-254854是分配给此漏洞的标识符。
cvss | epss | percentile |
---|---|---|
3.5 LOW | 0.04% | 12.26% |
references
CVE-2024-1920
description
A vulnerability, which was classified as critical, has been found in osuuu LightPicture up to 1.2.2. This issue affects the function handle of the file /app/middleware/TokenVerify.php. The manipulation leads to use of hard-coded cryptographic key . The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-254855.
description
截至1.2.2,在osuuu LightPicture中发现了一个被归类为关键的漏洞。此问题影响文件/app/middleware/TokenVerify.php的功能句柄。该操作导致使用硬编码的加密密钥。攻击可以远程启动。攻击的复杂性相当高。众所周知,开采是困难的。该漏洞已向公众公开,并可能被利用。此漏洞的相关标识符为VDB-254855。
cvss | epss | percentile |
---|---|---|
5.6 MEDIUM | 0.04% | 12.26% |
references
- https://note.zhaoj.in/share/gKyCbSSdJ5fY
- https://vuldb.com/?ctiid.254855
- https://vuldb.com/?id.254855
CVE-2024-1921
description
A vulnerability, which was classified as critical, was found in osuuu LightPicture up to 1.2.2. Affected is an unknown function of the file /app/controller/Setup.php. The manipulation leads to unrestricted upload. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-254856.
description
在1.2.2之前的osuuu LightPicture中发现了一个被归类为关键的漏洞。受影响的是文件/app/controller/Setup.php的未知功能。这种操作会导致不受限制的上传。可以远程发起攻击。该漏洞已向公众公开,并可能被利用。此漏洞的标识符为VDB-254856。
cvss | epss | percentile |
---|---|---|
4.7 MEDIUM | 0.04% | 12.26% |
references
- https://note.zhaoj.in/share/FeCRflSHPLbj
- https://vuldb.com/?ctiid.254856
- https://vuldb.com/?id.254856
CVE-2024-1922
description
A vulnerability has been found in SourceCodester Online Job Portal 1.0 and classified as problematic. Affected by this vulnerability is an unknown functionality of the file /Employer/ManageJob.php of the component Manage Job Page. The manipulation of the argument Qualification/Description leads to cross site scripting. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-254857 was assigned to this vulnerability.
description
在SourceCodester Online Job Portal 1.0中发现一个漏洞,并将其归类为有问题。受此漏洞影响的是组件Manage Job Page的文件/EEmployer/ManageJob.php的未知功能。参数Qualification/Description的操作会导致跨站点脚本编写。可以远程发起攻击。该漏洞已向公众公开,并可能被利用。标识符VDB-254857已分配给此漏洞。
cvss | epss | percentile |
---|---|---|
3.5 LOW | 0.04% | 12.26% |
references
- https://prnt.sc/WD3nof5FsEBv
- https://prnt.sc/zw3SnPnfpKGu
- https://vuldb.com/?ctiid.254857
- https://vuldb.com/?id.254857
CVE-2024-1923
description
A vulnerability was found in SourceCodester Simple Student Attendance System 1.0 and classified as critical. Affected by this issue is the function delete_class of the file /ajax-api.php of the component List of Classes Page. The manipulation of the argument id with the input 1337+or+1=1;–+ leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. VDB-254858 is the identifier assigned to this vulnerability.
description
在SourceCodester Simple Student Attendance System 1.0中发现一个漏洞,该漏洞被归类为严重漏洞。受此问题影响的是组件类列表页面的文件/ajax-api.php的函数delete_class。输入1337+或+1=1的参数id的操作;–+导致sql注入。攻击可能是远程发起的。该漏洞已向公众公开,并可能被利用。VDB-254858是分配给此漏洞的标识符。
cvss | epss | percentile |
---|---|---|
6.3 MEDIUM | 0.04% | 12.26% |
references
- https://github.com/smurf-reigz/security/blob/main/proof-of-concepts/SOURCECODESTER%20%5BSimple%20Student%20Attendance%20System%20using%20PHP%20and%20MySQL%5D%20SQLi%20on%20ajax-api.php%3Faction=delete_class.md
- https://vuldb.com/?ctiid.254858
- https://vuldb.com/?id.254858
CVE-2024-1924
description
A vulnerability was found in CodeAstro Membership Management System 1.0. It has been classified as critical. This affects an unknown part of the file /get_membership_amount.php. The manipulation of the argument membershipTypeId leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-254859.
description
在CodeAstro成员管理系统1.0中发现一个漏洞。它被列为关键。这会影响文件/get_membership_amount.php的未知部分。对参数membershipTypeId的操作导致sql注入。可以远程发起攻击。该漏洞已向公众公开,并可能被利用。此漏洞的相关标识符为VDB-254859。
cvss | epss | percentile |
---|---|---|
6.3 MEDIUM | 0.04% | 12.26% |
references
- https://github.com/1testnew/CVE_Hunter/blob/main/SQLi-1.md
- https://vuldb.com/?ctiid.254859
- https://vuldb.com/?id.254859
CVE-2024-1925
description
A vulnerability was found in Ctcms 2.1.2. It has been declared as critical. This vulnerability affects unknown code of the file ctcms/apps/controllers/admin/Upsys.php. The manipulation leads to unrestricted upload. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-254860.
description
在Ctcms 2.1.2中发现一个漏洞。它已被宣布为关键。此漏洞影响文件ctcms/apps/controllers/admin/Upsys.php的未知代码。这种操作会导致不受限制的上传。可以远程发起攻击。攻击的复杂性相当高。开采似乎很困难。该漏洞已向公众公开,并可能被利用。此漏洞的标识符为VDB-254860。
cvss | epss | percentile |
---|---|---|
5.0 MEDIUM | 0.04% | 12.26% |
references
- https://docs.qq.com/doc/DQkVmRXBlbGNPZmlL
- https://vuldb.com/?ctiid.254860
- https://vuldb.com/?id.254860
CVE-2024-1926
description
A vulnerability was found in SourceCodester Free and Open Source Inventory Management System 1.0. It has been rated as critical. This issue affects some unknown processing of the file /app/ajax/search_sales_report.php. The manipulation of the argument customer leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-254861 was assigned to this vulnerability.
description
在SourceCodester Free and Open Source Inventory Management System 1.0中发现一个漏洞。它被评为关键。此问题影响了对文件/app/ajax/search_sales_port.php的一些未知处理。对参数customer的操作导致sql注入。攻击可以远程启动。该漏洞已向公众公开,并可能被利用。标识符VDB-254861已分配给此漏洞。
cvss | epss | percentile |
---|---|---|
6.3 MEDIUM | 0.04% | 12.26% |
references
- https://github.com/xiahao90/CVEproject/blob/main/xiahao.webray.com.cn/Free%20and%20Open%20Source%20inventory%20management%20system-SQLi.md
- https://vuldb.com/?ctiid.254861
- https://vuldb.com/?id.254861
CVE-2024-1927
description
A vulnerability classified as critical was found in SourceCodester Web-Based Student Clearance System 1.0. Affected by this vulnerability is an unknown functionality of the file /Admin/login.php. The manipulation of the argument txtpassword leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-254863.
description
在SourceCodester基于Web的学生许可系统1.0中发现一个被归类为关键的漏洞。受此漏洞影响的是文件/Admin/login.php的未知功能。参数txtpassword的操作导致sql注入。可以远程发起攻击。该漏洞已向公众公开,并可能被利用。此漏洞的相关标识符为VDB-254863。
cvss | epss | percentile |
---|---|---|
6.3 MEDIUM | 0.04% | 12.26% |
references
- https://github.com/xiahao90/CVEproject/blob/main/xiahao.webray.com.cn/Web-Based%20Student%20Clearance%20System%20-%20SQLi.md
- https://vuldb.com/?ctiid.254863
- https://vuldb.com/?id.254863
CVE-2024-1928
description
A vulnerability, which was classified as critical, has been found in SourceCodester Web-Based Student Clearance System 1.0. Affected by this issue is some unknown functionality of the file /admin/edit-admin.php of the component Edit User Profile Page. The manipulation of the argument Fullname leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-254864.
description
在SourceCodester基于Web的学生许可系统1.0中发现了一个被归类为关键的漏洞。受此问题影响的是组件“编辑用户配置文件页”的文件/admin/edit-admin.php的一些未知功能。对参数Fullname的操作导致sql注入。攻击可能是远程发起的。该漏洞已向公众公开,并可能被利用。此漏洞的标识符为VDB-254864。
cvss | epss | percentile |
---|---|---|
4.7 MEDIUM | 0.04% | 12.26% |
references
- https://github.com/xiahao90/CVEproject/blob/main/xiahao.webray.com.cn/Web-Based%20Student%20Clearance%20System%20-%20XSS.md
- https://vuldb.com/?ctiid.254864
- https://vuldb.com/?id.254864
CVE-2024-21742
description
Improper input validation allows for header injection in MIME4J library when using MIME4J DOM for composing message. This can be exploited by an attacker to add unintended headers to MIME messages.
description
当使用MIME4J DOM编写消息时,不正确的输入验证允许在MIME4J库中注入头。攻击者可以利用此漏洞向MIME消息添加意外的标头。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- http://www.openwall.com/lists/oss-security/2024/02/27/5
- https://lists.apache.org/thread/nrqzg93219wdj056pqfszsd33dc54kfy
CVE-2024-22251
description
VMware Workstation and Fusion contain an out-of-bounds read vulnerability in the USB CCID (chip card interface device). A malicious actor with local administrative privileges on a virtual machine may trigger an out-of-bounds read leading to information disclosure.
description
VMware Workstation和Fusion在USB CCID(芯片卡接口设备)中包含越界读取漏洞。在虚拟机上具有本地管理权限的恶意行为者可能会触发越界读取,从而导致信息泄露。
cvss | epss | percentile |
---|---|---|
5.9 MEDIUM | 0.04% | 6.87% |
references
CVE-2024-22543
description
An issue was discovered in Linksys Router E1700 1.0.04 (build 3), allows authenticated attackers to escalate privileges via a crafted GET request to the /goform/* URI or via the ExportSettings function.
description
在Linksys路由器E1700 1.0.04(内部版本3)中发现一个问题,通过该问题,经过身份验证的攻击者可以通过特制的GET请求或ExportSettings函数将权限提升到/goform/*URI。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-22544
description
An issue was discovered in Linksys Router E1700 version 1.0.04 (build 3), allows authenticated attackers to execute arbitrary code via the setDateTime function.
description
在Linksys Router E1700 1.0.04版本(内部版本3)中发现一个问题,该问题允许经过身份验证的攻击者通过setDateTime函数执行任意代码。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-22917
description
SQL injection vulnerability in Dynamic Lab Management System Project in PHP v.1.0 allows a remote attacker to execute arbitrary code via a crafted script.
description
PHP v.1.0中的动态实验室管理系统项目中存在SQL注入漏洞,远程攻击者可以通过特制的脚本执行任意代码。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-24027
description
SQL Injection vulnerability in Likeshop before 2.5.7 allows attackers to run abitrary SQL commands via the function DistributionMemberLogic::getFansLists.
description
Likeshop 2.5.7之前版本中的SQL注入漏洞允许攻击者通过函数DistributionMemberLogic::getFansLists运行任意SQL命令。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-24095
description
Code-projects Simple Stock System 1.0 is vulnerable to SQL Injection.
description
代码项目Simple Stock System 1.0易受SQL注入攻击。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-24096
description
Code-projects Computer Book Store 1.0 is vulnerable to SQL Injection via BookSBIN.
description
代码项目Computer Book Store 1.0易受BookSBIN SQL注入的攻击。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-24099
description
Code-projects Scholars Tracking System 1.0 is vulnerable to SQL Injection under Employment Status Information Update.
description
代码项目学者跟踪系统1.0在就业状态信息更新下易受SQL注入的攻击。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-24100
description
Code-projects Computer Book Store 1.0 is vulnerable to SQL Injection via PublisherID.
description
代码项目Computer Book Store 1.0易受通过PublisherID进行SQL注入的攻击。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-24323
description
SQL injection vulnerability in linlinjava litemall v.1.8.0 allows a remote attacker to obtain sensitive information via the nickname, consignee, orderSN, orderStatusArray parameters of the AdminOrdercontroller.java component.
description
linlinjava litemall v.1.8.0中的SQL注入漏洞允许远程攻击者通过AdminOrdercontroller.java组件的昵称、收货人、orderSN、orderStatusArray参数获取敏感信息。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-24720
description
An issue was discovered on Innovaphone PBX before 14r1 devices. It provides different responses to incoming requests in a way that reveals information to an attacker.
description
在14r1设备之前的Innovaphone PBX上发现了一个问题。它以向攻击者透露信息的方式对传入请求提供不同的响应。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-25166
description
Cross Site Scripting vulnerability in 71CMS v.1.0.0 allows a remote attacker to execute arbitrary code via the uploadfile action parameter in the controller.php file.
description
71CMS v.1.0.0中的跨站点脚本漏洞允许远程攻击者通过controller.php文件中的uploadfile操作参数执行任意代码。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-25398
description
In Srelay (the SOCKS proxy and Relay) v.0.4.8p3, a specially crafted network payload can trigger a denial of service condition and disrupt the service.
description
在Srelay(SOCKS代理和中继)v.0.4.8p3中,特制的网络负载可能会触发拒绝服务条件并中断服务。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://github.com/Nivedita-22/SRELAY-exploit-writeup/blob/main/Srelay.md
- https://sourceforge.net/projects/socks-relay/
CVE-2024-25399
description
Subrion CMS 4.2.1 is vulnerable to Cross Site Scripting (XSS) via adminer.php.
description
Subrion CMS 4.2.1易受adminer.php跨站点脚本(XSS)攻击。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-25400
description
Subrion CMS 4.2.1 is vulnerable to SQL Injection via ia.core.mysqli.php.
description
Subrion CMS 4.2.1易受ia.core.mysqli.php的SQL注入攻击。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://cwe.mitre.org/data/definitions/89.html
- https://github.com/intelliants/subrion/issues/910
- https://subrion.org/
CVE-2024-25723
description
ZenML Server in the ZenML machine learning package before 0.46.7 for Python allows remote privilege escalation because the /api/v1/users/{user_name_or_id}/activate REST API endpoint allows access on the basis of a valid username along with a new password in the request body. These are also patched versions: 0.44.4, 0.43.1, and 0.42.2.
description
Python 0.46.7之前的ZenML机器学习包中的ZenML Server允许远程权限提升,因为/api/v1/users/{user_name_or_id}/activate REST api端点允许基于有效用户名和请求主体中的新密码进行访问。这些也是修补版本:0.44.4、0.43.1和0.42.2。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://github.com/zenml-io/zenml
- https://github.com/zenml-io/zenml/compare/0.42.1...0.42.2
- https://github.com/zenml-io/zenml/compare/0.43.0...0.43.1
- https://github.com/zenml-io/zenml/compare/0.44.3...0.44.4
- https://www.zenml.io/blog/critical-security-update-for-zenml-users
CVE-2024-25840
description
In the module “Account Manager | Sales Representative & Dealers | CRM” (prestasalesmanager) up to 9.0 from Presta World for PrestaShop, a guest can download personal information without restriction by performing a path traversal attack.
description
在Presta World for PrestaShop的“Account Manager | Sales Representative&Dealers | CRM”(prestasalemanager)模块(最高9.0)中,客人可以通过执行路径遍历攻击无限制地下载个人信息。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://addons.prestashop.com/en/third-party-data-integrations-crm-erp/90816-account-manager-sales-representative-dealers-crm.html
- https://security.friendsofpresta.org/modules/2024/02/27/prestasalesmanager.html
CVE-2024-25841
description
In the module “So Flexibilite” (soflexibilite) from Common-Services for PrestaShop < 4.1.26, a guest (authenticated customer) can perform Cross Site Scripting (XSS) injection.
description
在Common Services for PrestaShop<4.1.26的模块“So Flexibilite”(soflexibilite)中,访客(经过身份验证的客户)可以执行跨站点脚本(XSS)注入。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://addons.prestashop.com/fr/transporteurs/2704-colissimo-domicile-et-points-de-retrait.html
- https://security.friendsofpresta.org/modules/2024/02/27/soflexibilite.html
CVE-2024-25843
description
In the module “Import/Update Bulk Product from any Csv/Excel File Pro” (ba_importer) up to version 1.1.28 from Buy Addons for PrestaShop, a guest can perform SQL injection in affected versions.
description
在Buy Addons for PrestaShop版本1.1.28之前的模块“从任何Csv/Excel File Pro导入/更新批量产品”(ba_importer)中,访客可以在受影响的版本中执行SQL注入。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://addons.prestashop.com/en/data-import-export/20579-import-update-bulk-product-from-any-csv-excel-file-pro.html
- https://security.friendsofpresta.org/modules/2024/02/27/ba_importer.html
CVE-2024-25846
description
In the module “Product Catalog (CSV, Excel) Import” (simpleimportproduct) <= 6.7.0 from MyPrestaModules for PrestaShop, a guest can upload files with extensions .php.
description
在MyPrestaModules for PrestaShop的模块“产品目录(CSV,Excel)导入”(simpleimportproduct)<=6.7.0中,客人可以上传扩展名为.php的文件。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://addons.prestashop.com/fr/import-export-de-donnees/19091-catalogue-de-produits-csv-excel-dimportation.html
- https://security.friendsofpresta.org/modules/2024/02/27/simpleimportproduct.html
CVE-2024-26142
description
Rails is a web-application framework. Starting in version 7.1.0, there is a possible ReDoS vulnerability in the Accept header parsing routines of Action Dispatch. This vulnerability is patched in 7.1.3.1. Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected.
description
Rails是一个web应用程序框架。从7.1.0版本开始,Action Dispatch的Accept标头解析例程中可能存在ReDoS漏洞。此漏洞已在7.1.3.1中修补。Ruby 3.2对此问题有缓解措施,因此使用Ruby 3.2或更新版本的Rails应用程序不会受到影响。
cvss | epss | percentile |
---|---|---|
7.5 HIGH | 0.04% | 12.26% |
references
- https://discuss.rubyonrails.org/t/possible-redos-vulnerability-in-accept-header-parsing-in-action-dispatch/84946
- https://github.com/rails/rails/commit/b4d3bfb5ed8a5b5a90aad3a3b28860c7a931e272
- https://github.com/rails/rails/security/advisories/GHSA-jjhx-jhvp-74wq
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/actionpack/CVE-2024-26142.yml
CVE-2024-26143
description
Rails is a web-application framework. There is a possible XSS vulnerability when using the translation helpers in Action Controller. Applications using translation methods like translate, or t on a controller, with a key ending in “_html”, a :default key which contains untrusted user input, and the resulting string is used in a view, may be susceptible to an XSS vulnerability. The vulnerability is fixed in 7.1.3.1 and 7.0.8.1.
description
Rails是一个web应用程序框架。在Action Controller中使用翻译助手时可能存在XSS漏洞。使用翻译方法(如控制器上的translate或t)的应用程序,其密钥以“_html”结尾,这是一个:默认密钥,包含不受信任的用户输入,并且生成的字符串在视图中使用,可能容易受到XSS漏洞的影响。该漏洞已在7.1.3.1和7.0.8.1中修复。
cvss | epss | percentile |
---|---|---|
6.1 MEDIUM | 0.04% | 12.26% |
references
- https://discuss.rubyonrails.org/t/possible-xss-vulnerability-in-action-controller/84947
- https://github.com/rails/rails/commit/4c83b331092a79d58e4adffe4be5f250fa5782cc
- https://github.com/rails/rails/commit/5187a9ef51980ad1b8e81945ebe0462d28f84f9e
- https://github.com/rails/rails/security/advisories/GHSA-9822-6m93-xqf4
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/actionpack/CVE-2024-26143.yml
CVE-2024-26144
description
Rails is a web-application framework. Starting with version 5.2.0, there is a possible sensitive session information leak in Active Storage. By default, Active Storage sends a Set-Cookie header along with the users session cookie when serving blobs. It also sets Cache-Control to public. Certain proxies may cache the Set-Cookie, leading to an information leak. The vulnerability is fixed in 7.0.8.1 and 6.1.7.7.
description
Rails是一个web应用程序框架。从5.2.0版本开始,Active Storage中可能存在敏感会话信息泄漏。默认情况下,Active Storage在提供Blob时会将Set Cookie标头与用户会话Cookie一起发送。它还将“缓存控制”设置为public。某些代理可能会缓存Set Cookie,从而导致信息泄露。该漏洞已在7.0.8.1和6.1.7.7中修复。
cvss | epss | percentile |
---|---|---|
5.3 MEDIUM | 0.04% | 12.26% |
references
- https://discuss.rubyonrails.org/t/possible-sensitive-session-information-leak-in-active-storage/84945
- https://github.com/rails/rails/commit/723f54566023e91060a67b03353e7c03e7436433
- https://github.com/rails/rails/commit/78fe149509fac5b05e54187aaaef216fbb5fd0d3
- https://github.com/rails/rails/security/advisories/GHSA-8h22-8cf7-hq6g
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/activestorage/CVE-2024-26144.yml
CVE-2024-26294
description
Vulnerabilities in the ClearPass Policy Manager web-based management interface allow remote authenticated users to run arbitrary commands on the underlying host. A successful exploit could allow an attacker to execute arbitrary commands as root on the underlying operating system leading to complete system compromise.
description
ClearPass Policy Manager基于web的管理界面中存在漏洞,允许经过远程身份验证的用户在底层主机上运行任意命令。成功利用此漏洞可使攻击者以root用户身份在底层操作系统上执行任意命令,从而导致系统完全崩溃。
cvss | epss | percentile |
---|---|---|
7.2 HIGH | 0.04% | 6.87% |
references
CVE-2024-26295
description
Vulnerabilities in the ClearPass Policy Manager web-based management interface allow remote authenticated users to run arbitrary commands on the underlying host. A successful exploit could allow an attacker to execute arbitrary commands as root on the underlying operating system leading to complete system compromise.
description
ClearPass Policy Manager基于web的管理界面中存在漏洞,允许经过远程身份验证的用户在底层主机上运行任意命令。成功利用此漏洞可使攻击者以root用户身份在底层操作系统上执行任意命令,从而导致系统完全崩溃。
cvss | epss | percentile |
---|---|---|
7.2 HIGH | 0.04% | 6.87% |
references
CVE-2024-26296
description
Vulnerabilities in the ClearPass Policy Manager web-based management interface allow remote authenticated users to run arbitrary commands on the underlying host. A successful exploit could allow an attacker to execute arbitrary commands as root on the underlying operating system leading to complete system compromise.
description
ClearPass Policy Manager基于web的管理界面中存在漏洞,允许经过远程身份验证的用户在底层主机上运行任意命令。成功利用此漏洞可使攻击者以root用户身份在底层操作系统上执行任意命令,从而导致系统完全崩溃。
cvss | epss | percentile |
---|---|---|
7.2 HIGH | 0.04% | 6.87% |
references
CVE-2024-26297
description
Vulnerabilities in the ClearPass Policy Manager web-based management interface allow remote authenticated users to run arbitrary commands on the underlying host. A successful exploit could allow an attacker to execute arbitrary commands as root on the underlying operating system leading to complete system compromise.
description
ClearPass Policy Manager基于web的管理界面中存在漏洞,允许经过远程身份验证的用户在底层主机上运行任意命令。成功利用此漏洞可使攻击者以root用户身份在底层操作系统上执行任意命令,从而导致系统完全崩溃。
cvss | epss | percentile |
---|---|---|
7.2 HIGH | 0.04% | 6.87% |
references
CVE-2024-26298
description
Vulnerabilities in the ClearPass Policy Manager web-based management interface allow remote authenticated users to run arbitrary commands on the underlying host. A successful exploit could allow an attacker to execute arbitrary commands as root on the underlying operating system leading to complete system compromise.
description
ClearPass Policy Manager基于web的管理界面中存在漏洞,允许经过远程身份验证的用户在底层主机上运行任意命令。成功利用此漏洞可使攻击者以root用户身份在底层操作系统上执行任意命令,从而导致系统完全崩溃。
cvss | epss | percentile |
---|---|---|
7.2 HIGH | 0.04% | 6.87% |
references
CVE-2024-26299
description
A vulnerability in the web-based management interface of ClearPass Policy Manager could allow an authenticated remote attacker to conduct a stored cross-site scripting (XSS) attack against an administrative user of the interface. A successful exploit allows an attacker to execute arbitrary script code in a victims browser in the context of the affected interface.
description
ClearPass Policy Manager基于web的管理界面中存在漏洞,通过该漏洞,经过身份验证的远程攻击者可以对该界面的管理用户进行存储的跨站点脚本(XSS)攻击。成功利用此漏洞,攻击者可以在受害者浏览器中受影响界面的上下文中执行任意脚本代码。
cvss | epss | percentile |
---|---|---|
6.6 MEDIUM | 0.04% | 6.87% |
references
CVE-2024-26300
description
A vulnerability in the guest interface of ClearPass Policy Manager could allow an authenticated remote attacker to conduct a stored cross-site scripting (XSS) attack against an administrative user of the interface. A successful exploit allows an attacker to execute arbitrary script code in a victims browser in the context of the affected interface.
description
ClearPass策略管理器的来宾界面中存在漏洞,通过身份验证的远程攻击者可以对该界面的管理用户进行存储的跨站点脚本(XSS)攻击。成功利用此漏洞,攻击者可以在受害者浏览器中受影响界面的上下文中执行任意脚本代码。
cvss | epss | percentile |
---|---|---|
6.6 MEDIUM | 0.04% | 6.87% |
references
CVE-2024-26301
description
A vulnerability in the web-based management interface of ClearPass Policy Manager could allow a remote attacker authenticated with low privileges to access sensitive information. A successful exploit allows an attacker to retrieve information which could be used to potentially gain further access to network services supported by ClearPass Policy Manager.
description
ClearPass策略管理器基于web的管理界面中存在漏洞,通过该漏洞,通过低权限身份验证的远程攻击者可以访问敏感信息。成功利用此漏洞,攻击者可以检索可用于进一步访问ClearPass策略管理器支持的网络服务的信息。
cvss | epss | percentile |
---|---|---|
6.5 MEDIUM | 0.04% | 6.87% |
references
CVE-2024-26302
description
A vulnerability in the web-based management interface of ClearPass Policy Manager could allow a remote attacker authenticated with low privileges to access sensitive information. A successful exploit allows an attacker to retrieve information which could be used to potentially gain further access to network services supported by ClearPass Policy Manager.
description
ClearPass策略管理器基于web的管理界面中存在漏洞,通过该漏洞,通过低权限身份验证的远程攻击者可以访问敏感信息。成功利用此漏洞,攻击者可以检索可用于进一步访问ClearPass策略管理器支持的网络服务的信息。
cvss | epss | percentile |
---|---|---|
4.8 MEDIUM | 0.04% | 6.87% |
references
CVE-2024-26464
description
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
description
拒绝不要使用此候选号码。咨询ID:无。原因:此候选人已被其CNA撤回。进一步调查表明,这不是一个安全问题。注:无。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
CVE-2024-26470
description
A host header injection vulnerability in the forgot password function of FullStackHeros WebAPI Boilerplate v1.0.0 and v1.0.1 allows attackers to leak the password reset token via a crafted request.
description
FullStackHeros WebAPI Boilerplate v1.0.0和v1.0.1的忘记密码功能中存在主机头注入漏洞,攻击者可以通过特制的请求泄露密码重置令牌。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://github.com/dub-flow/vulnerability-research/tree/main/CVE-2024-26470
- https://github.com/fullstackhero/dotnet-webapi-boilerplate
- https://www.nuget.org/packages/FullStackHero.WebAPI.Boilerplate
CVE-2024-26471
description
A reflected cross-site scripting (XSS) vulnerability in zhimengzhe iBarn v1.5 allows attackers to inject malicious JavaScript into the web browser of a victim via the search parameter in offer.php.
description
智梦哲iBarn v1.5中存在一个反映跨站点脚本(XSS)漏洞,攻击者可以通过offer.php中的搜索参数将恶意JavaScript注入受害者的web浏览器。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://github.com/dub-flow/vulnerability-research/tree/main/CVE-2024-26471
- https://github.com/zhimengzhe/iBarn
CVE-2024-26472
description
A reflected cross-site scripting (XSS) vulnerability in SocialMediaWebsite v1.0.1 allows attackers to inject malicious JavaScript into the web browser of a victim via the selector or validator parameters in offer.php.
description
SocialMediaWebsite v1.0.1中存在一个反映的跨站点脚本(XSS)漏洞,攻击者可以通过offer.php中的选择器或验证器参数将恶意JavaScript注入受害者的web浏览器。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://github.com/dub-flow/vulnerability-research/tree/main/CVE-2024-26472
- https://github.com/msaad1999/KLiK-SocialMediaWebsite/
CVE-2024-26473
description
A reflected cross-site scripting (XSS) vulnerability in SocialMediaWebsite v1.0.1 allows attackers to inject malicious JavaScript into the web browser of a victim via the poll parameter in poll.php.
description
SocialMediaWebsite v1.0.1中存在一个反映的跨站点脚本(XSS)漏洞,攻击者可以通过poll.php中的poll参数将恶意JavaScript注入受害者的web浏览器。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://github.com/dub-flow/vulnerability-research/tree/main/CVE-2024-26473
- https://github.com/msaad1999/KLiK-SocialMediaWebsite/
CVE-2024-26542
description
Cross Site Scripting vulnerability in Bonitasoft, S.A v.7.14. and fixed in v.9.0.2, 8.0.3, 7.15.7, 7.14.8 allows attackers to execute arbitrary code via a crafted payload to the Groups Display name field.
description
Bonitasoft,S.A v.7.14中存在跨站点脚本漏洞。在v.9.0.2、8.0.3、7.15.7和7.14.8中修复的漏洞允许攻击者通过特制的组显示名称字段有效载荷执行任意代码。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-27099
description
The uAMQP is a C library for AMQP 1.0 communication to Azure Cloud Services. When processing an incorrect AMQP_VALUE
failed state, may cause a double free problem. This may cause a RCE. Update submodule with commit 2ca42b6e4e098af2d17e487814a91d05f6ae4987.
description
uAMQP是一个用于AMQP 1.0与Azure云服务通信的C库。处理不正确的“AMQP_VALUE”失败状态时,可能会导致双空闲问题。这可能会导致RCE。使用commit 2ca42b6e4e098af2d17e487814a91d05f6ae4987更新子模块。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
CVE-2024-27356
description
An issue was discovered on certain GL-iNet devices. Attackers can download files such as logs via commands, potentially obtaining critical user information. This affects MT6000 4.5.5, XE3000 4.4.4, X3000 4.4.5, MT3000 4.5.0, MT2500 4.5.0, AXT1800 4.5.0, AX1800 4.5.0, A1300 4.5.0, S200 4.1.4-0300, X750 4.3.7, SFT1200 4.3.7, XE300 4.3.7, MT1300 4.3.10, AR750 4.3.10, AR750S 4.3.10, AR300M 4.3.10, AR300M16 4.3.10, B1300 4.3.10, MT300N-v2 4.3.10, X300B 3.217, S1300 3.216, SF1200 3.216, MV1000 3.216, N300 3.216, B2200 3.216, and X1200 3.203.
description
在某些GL iNet设备上发现问题。攻击者可以通过命令下载日志等文件,从而可能获得关键的用户信息。这会影响MT6000 4.5.5、XE3000 4.4.4、X3000 4.4.5、MT3000 4.5.0、MT2500 4.5.0、AXT1800 4.5.0、AX1000 4.5.0、A1300 4.5.0、S200 4.1.4-0300、X750 4.3.7、SFT1200 4.3.7、XE300 4.3.7、MT1300 4.3.10、AR750 4.3.10、AR 750S 4.3.10、ar 300m 4.3.10、AR300M16 4.3.10、B1300 4.3.10、MT300N-v2 4.3.10、X300B 3.217、S1300 3.216、SF1200 3.216、MV1000 3.216、N300 3.216,B2200 3.216和X1200 3.203。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- https://github.com/gl-inet/CVE-issues/blob/main/4.0.0/Download_file_vulnerability.md
- https://gl-inet.com
CVE-2024-27507
description
libLAS 1.8.1 contains a memory leak vulnerability in /libLAS/apps/ts2las.cpp.
description
libLAS 1.8.1在/libLAS/apps/ts2las.cpp中包含内存泄漏漏洞。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-27508
description
Atheme 7.2.12 contains a memory leak vulnerability in /atheme/src/crypto-benchmark/main.c.
description
Atheme 7.2.12在/Atheme/src/crypto-bbenchmark/main.c中包含内存泄漏漏洞。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
CVE-2024-27905
description
** UNSUPPORTED WHEN ASSIGNED ** Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Aurora. An endpoint exposing internals to unauthenticated users can be used as a “padding oracle” allowing an anonymous attacker to construct a valid authentication cookie. Potentially this could be combined with vulnerabilities in other components to achieve remote code execution. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
description
分配时不支持敏感信息暴露于Apache Aurora中未经授权的Actor漏洞。向未经身份验证的用户公开内部的端点可以用作“填充预言机”,允许匿名攻击者构建有效的身份验证cookie。这可能与其他组件中的漏洞相结合,以实现远程代码执行。由于此项目已退役,我们不打算发布修复此问题的版本。建议用户找到替代方案,或将对实例的访问权限限制为受信任的用户。注意:此漏洞只影响维护人员不再支持的产品。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
references
- http://www.openwall.com/lists/oss-security/2024/02/27/3
- https://lists.apache.org/thread/564kbv3wqdzkscmdn2bg4vlk48qymryp
Modified_entries
CVE-2019-25161
description
** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
description
拒绝此CVE ID已被其CVE编号机构拒绝或撤回。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |
CVE-2023-32307
description
Sofia-SIP is an open-source SIP User-Agent library, compliant with the IETF RFC3261 specification. Referring to GHSA-8599-x7rq-fr54, several other potential heap-over-flow and integer-overflow in stun_parse_attr_error_code and stun_parse_attr_uint32 were found because the lack of attributes length check when Sofia-SIP handles STUN packets. The previous patch of GHSA-8599-x7rq-fr54 fixed the vulnerability when attr_type did not match the enum value, but there are also vulnerabilities in the handling of other valid cases. The OOB read and integer-overflow made by attacker may lead to crash, high consumption of memory or even other more serious consequences. These issue have been addressed in version 1.13.15. Users are advised to upgrade.
description
Sofia SIP是一个开源的SIP用户代理库,符合IETF RFC3261规范。参考【GHSA-8599-x7rq-fr54】(https://github.com/freeswitch/sofia-sip/security/advisories/GHSA-8599-x7rq-fr54),由于Sofia SIP处理stun数据包时缺乏属性长度检查,在stun_passe_attr_error_code和stun_pass_attr_uint32中发现了其他几个潜在的堆溢出和整数溢出。先前的补丁GHSA-8599-x7rq-fr54修复了attr_type与enum值不匹配时的漏洞,但在处理其他有效情况时也存在漏洞。攻击者进行的OOB读取和整数溢出可能导致崩溃、高内存消耗甚至其他更严重的后果。1.13.15版本中已解决了这些问题。建议用户升级。
cvss | epss | percentile |
---|---|---|
7.5 HIGH | 0.05% | 16.42% |
references
- https://github.com/freeswitch/sofia-sip/security/advisories/GHSA-rm4c-ccvf-ff9c
- https://lists.debian.org/debian-lts-announce/2023/06/msg00002.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OY66DOQ3B7GULJTI66X5HNX5FU3P65CX/
- https://www.debian.org/security/2023/dsa-5431
CVE-2023-38852
description
Buffer Overflow vulnerability in libxlsv.1.6.2 allows a remote attacker to execute arbitrary code and cause a denial of service via a crafted XLS file to the unicode_decode_wcstombs function in xlstool.c:266.
description
libxlsv.1.6.2中的缓冲区溢出漏洞使远程攻击者能够执行任意代码,并通过特制的XLS文件对xlstol.c:266中的unicode_decode_wcstombs函数造成拒绝服务。
cvss | epss | percentile |
---|---|---|
None | 0.14% | 48.92% |
references
- https://github.com/libxls/libxls/issues/124
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JQYGEBDBCOWBRHOW44BSSRADUOZBXHUE/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YHBUPYF2NX34HNAWZ3WYHKWU3KWVQUSV/
CVE-2023-4194
description
A flaw was found in the Linux kernels TUN/TAP functionality. This issue could allow a local user to bypass network filters and gain unauthorized access to some resources. The original patches fixing CVE-2023-1076 are incorrect or incomplete. The problem is that the following upstream commits - a096ccca6e50 (“tun: tun_chr_open(): correctly initialize socket uid”), - 66b2c338adce (“tap: tap_open(): correctly initialize socket uid”), pass “inode->i_uid” to sock_init_data_uid() as the last parameter and that turns out to not be accurate.
description
在Linux内核TUN/TAP功能中发现了一个缺陷。此问题可能允许本地用户绕过网络筛选器,获得对某些资源的未经授权的访问权限。固定CVE-2023-1076的原始补丁不正确或不完整。问题是,以下上游提交-a096ccca6e50(“tun:tun_chr_open():正确初始化套接字uid”),-66b2c338adce(“tap:tap_open):正确地初始化套接字uid”),将“inode->i_uid”作为最后一个参数传递给sock_init_data_uid(),结果证明这是不准确的。
cvss | epss | percentile |
---|---|---|
5.5 MEDIUM | 0.04% | 5.42% |
references
- https://access.redhat.com/errata/RHSA-2023:6583
- https://access.redhat.com/security/cve/CVE-2023-4194
- https://bugzilla.redhat.com/show_bug.cgi?id=2229498
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/344H6HO6SSC4KT7PDFXSDIXKMKHISSGF/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3TYLSJ2SAI7RF56ZLQ5CQWCJLVJSD73Q/
- https://lore.kernel.org/all/20230731164237.48365-1-lersek@redhat.com/
- https://lore.kernel.org/all/20230731164237.48365-2-lersek@redhat.com/
- https://lore.kernel.org/all/20230731164237.48365-3-lersek@redhat.com/
- https://security.netapp.com/advisory/ntap-20231027-0002/
- https://www.debian.org/security/2023/dsa-5480
- https://www.debian.org/security/2023/dsa-5492
CVE-2023-42753
description
An array indexing vulnerability was found in the netfilter subsystem of the Linux kernel. A missing macro could lead to a miscalculation of the h->nets
array offset, providing attackers with the primitive to arbitrarily increment/decrement a memory buffer out-of-bound. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.
description
在Linux内核的netfilter子系统中发现数组索引漏洞。丢失的宏可能会导致“h->nets”数组偏移量的错误计算,从而为攻击者提供了任意递增/递减内存缓冲区的基元。此问题可能会导致本地用户使系统崩溃,或可能升级他们在系统上的权限。
cvss | epss | percentile |
---|---|---|
7.0 HIGH | 0.04% | 8.04% |
references
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7539
- https://access.redhat.com/errata/RHSA-2023:7558
- https://access.redhat.com/errata/RHSA-2024:0089
- https://access.redhat.com/errata/RHSA-2024:0113
- https://access.redhat.com/errata/RHSA-2024:0134
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0346
- https://access.redhat.com/errata/RHSA-2024:0347
- https://access.redhat.com/errata/RHSA-2024:0371
- https://access.redhat.com/errata/RHSA-2024:0376
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0402
- https://access.redhat.com/errata/RHSA-2024:0403
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:0999
- https://access.redhat.com/security/cve/CVE-2023-42753
- https://bugzilla.redhat.com/show_bug.cgi?id=2239843
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://seclists.org/oss-sec/2023/q3/216
- https://www.openwall.com/lists/oss-security/2023/09/22/10
CVE-2023-44211
description
Sensitive information disclosure and manipulation due to missing authorization. The following products are affected: Acronis Cyber Protect Cloud Agent (Linux, macOS, Windows) before build 31637, Acronis Cyber Protect 16 (Linux, Windows) before build 37391.
description
由于缺少授权而导致的敏感信息泄露和操纵。以下产品受到影响:版本31637之前的Acronis Cyber Protect Cloud Agent(Linux、macOS、Windows),版本37391之前的Aconis Cyber Protection 16(Linux、Windows)。
cvss | epss | percentile |
---|---|---|
7.1 HIGH | 0.04% | 6.87% |
references
CVE-2023-44213
description
Sensitive information disclosure due to excessive collection of system information. The following products are affected: Acronis Cyber Protect Cloud Agent (Windows) before build 35739, Acronis Cyber Protect 16 (Windows) before build 37391.
description
由于过度收集系统信息而导致的敏感信息泄露。以下产品受到影响:版本35739之前的Acronis Cyber Protect Cloud Agent(Windows),版本37391之前的Aconis Cyber Protection 16(Windows)。
cvss | epss | percentile |
---|---|---|
3.3 LOW | 0.04% | 6.87% |
references
CVE-2023-45241
description
Sensitive information leak through log files. The following products are affected: Acronis Cyber Protect Cloud Agent (Linux, macOS, Windows) before build 35739, Acronis Cyber Protect 16 (Linux, macOS, Windows) before build 37391.
description
敏感信息通过日志文件泄漏。以下产品受到影响:版本35739之前的Acronis Cyber Protect Cloud Agent(Linux、macOS、Windows),版本37391之前的Aconis Cyber Protection 16(Linux、macOS、Windows。
cvss | epss | percentile |
---|---|---|
4.4 MEDIUM | 0.04% | 6.87% |
references
CVE-2023-45244
description
Sensitive information disclosure and manipulation due to missing authorization. The following products are affected: Acronis Cyber Protect Cloud Agent (Linux, macOS, Windows) before build 35895, Acronis Cyber Protect 16 (Linux, macOS, Windows) before build 37391.
description
由于缺少授权而导致的敏感信息泄露和操纵。以下产品受到影响:版本35895之前的Acronis Cyber Protect Cloud Agent(Linux、macOS、Windows),版本37391之前的Aconis Cyber Protection 16(Linux、macOS、Windows。
cvss | epss | percentile |
---|---|---|
7.1 HIGH | 0.04% | 6.87% |
references
CVE-2023-45248
description
Local privilege escalation due to DLL hijacking vulnerability. The following products are affected: Acronis Cyber Protect Cloud Agent (Windows) before build 36497, Acronis Cyber Protect 16 (Windows) before build 37391.
description
由于DLL劫持漏洞,本地权限提升。以下产品受到影响:版本36497之前的Acronis Cyber Protect Cloud Agent(Windows),版本37391之前的Aconis Cyber Protection 16(Windows)。
cvss | epss | percentile |
---|---|---|
6.6 MEDIUM | 0.04% | 5.42% |
references
CVE-2023-52160
description
The implementation of PEAP in wpa_supplicant through 2.10 allows authentication bypass. For a successful attack, wpa_supplicant must be configured to not verify the networks TLS certificate during Phase 1 authentication, and an eap_peap_decrypt vulnerability can then be abused to skip Phase 2 authentication. The attack vector is sending an EAP-TLV Success packet instead of starting Phase 2. This allows an adversary to impersonate Enterprise Wi-Fi networks.
description
通过2.10在wpa_pplient中实现PEAP允许绕过身份验证。为了成功进行攻击,必须将wpa_pplient配置为在第1阶段身份验证期间不验证网络TLS证书,然后可以滥用eap_peap_decrypt漏洞跳过第2阶段身份验证。攻击向量正在发送EAP-TLV成功数据包,而不是开始阶段2。这允许对手模拟企业Wi-Fi网络。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.31% |
references
- https://lists.debian.org/debian-lts-announce/2024/02/msg00013.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/N46C4DTVUWK336OYDA4LGALSC5VVPTCC/
- https://w1.fi/cgit/hostap/commit/?id=8e6485a1bcb0baffdea9e55255a81270b768439c
- https://www.top10vpn.com/research/wifi-vulnerabilities/
CVE-2023-6267
description
A flaw was found in the json payload. If annotation based security is used to secure a REST resource, the JSON body that the resource may consume is being processed (deserialized) prior to the security constraints being evaluated and applied. This does not happen with configuration based security.
description
在json负载中发现了一个缺陷。如果使用基于注释的安全性来保护REST资源,则在评估和应用安全约束之前,将处理(反序列化)资源可能使用的JSON主体。基于配置的安全性不会发生这种情况。
cvss | epss | percentile |
---|---|---|
8.6 HIGH | 0.07% | 27.45% |
references
- https://access.redhat.com/errata/RHSA-2024:0494
- https://access.redhat.com/errata/RHSA-2024:0495
- https://access.redhat.com/security/cve/CVE-2023-6267
- https://bugzilla.redhat.com/show_bug.cgi?id=2251155
CVE-2024-1459
description
A path traversal vulnerability was found in Undertow. This issue may allow a remote attacker to append a specially-crafted sequence to an HTTP request for an application deployed to JBoss EAP, which may permit access to privileged or restricted files and directories.
description
在Undertow中发现路径遍历漏洞。此问题可能允许远程攻击者将特制的序列附加到部署到JBoss-EAP的应用程序的HTTP请求中,从而允许访问特权或受限的文件和目录。
cvss | epss | percentile |
---|---|---|
5.3 MEDIUM | 0.05% | 13.82% |
references
- https://access.redhat.com/security/cve/CVE-2024-1459
- https://bugzilla.redhat.com/show_bug.cgi?id=2259475
CVE-2024-1485
description
A flaw was found in the decompression function of registry-support. This issue can be triggered if an unauthenticated remote attacker tricks a user into parsing a devfile which uses the parent
or plugin
keywords. This could download a malicious archive and cause the cleanup process to overwrite or delete files outside of the archive, which should not be allowed.
description
在注册表支持的解压缩功能中发现了一个缺陷。如果未经身份验证的远程攻击者诱骗用户解析使用“parent”或“plugin”关键字的开发文件,则可能会触发此问题。这可能会下载恶意存档,并导致清理过程覆盖或删除存档之外的文件,这是不允许的。
cvss | epss | percentile |
---|---|---|
8.0 HIGH | 0.04% | 12.26% |
references
- https://access.redhat.com/security/cve/CVE-2024-1485
- https://bugzilla.redhat.com/show_bug.cgi?id=2264106
- https://github.com/advisories/GHSA-84xv-jfrm-h4gm
- https://github.com/devfile/registry-support/commit/0e44b9ca6d03fac4fc3f77d37656d56dc5defe0d
- https://github.com/devfile/registry-support/pull/197
CVE-2024-1886
description
This vulnerability allows remote attackers to traverse the directory on the affected webOS of LG Signage TV.
description
此漏洞允许远程攻击者遍历LG Signage TV受影响的webOS上的目录。
cvss | epss | percentile |
---|---|---|
3.0 LOW | 0.04% | 6.87% |
references
CVE-2024-21484
description
Versions of the package jsrsasign before 11.0.0 are vulnerable to Observable Discrepancy via the RSA PKCS1.5 or RSAOAEP decryption process. An attacker can decrypt ciphertexts by exploiting this vulnerability. Exploiting this vulnerability requires the attacker to have access to a large number of ciphertexts encrypted with the same key. Workaround The vulnerability can be mitigated by finding and replacing RSA and RSAOAEP decryption with another crypto library.
description
11.0.0之前的包jsrssign版本容易通过RSA PKCS1.5或RSAOAEP解密过程受到可观察差异的攻击。攻击者可以利用此漏洞解密密文。利用此漏洞需要攻击者能够访问使用相同密钥加密的大量密文。解决方法可以通过查找RSA和RSAOAEP解密并将其替换为另一个加密库来缓解该漏洞。
cvss | epss | percentile |
---|---|---|
7.5 HIGH | 0.08% | 33.60% |
references
- https://github.com/kjur/jsrsasign/issues/598
- https://github.com/kjur/jsrsasign/releases/tag/11.0.0
- https://people.redhat.com/~hkario/marvin/
- https://security.snyk.io/vuln/SNYK-JAVA-ORGWEBJARSBOWER-6070734
- https://security.snyk.io/vuln/SNYK-JAVA-ORGWEBJARSBOWERGITHUBKJUR-6070733
- https://security.snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-6070732
- https://security.snyk.io/vuln/SNYK-JS-JSRSASIGN-6070731
CVE-2024-22368
description
The Spreadsheet::ParseXLSX package before 0.28 for Perl can encounter an out-of-memory condition during parsing of a crafted XLSX document. This occurs because the memoize implementation does not have appropriate constraints on merged cells.
description
用于Perl的0.28之前的Spreadsheet::ParseXLSX包在解析精心编制的XLSX文档时可能会遇到内存不足的情况。之所以会出现这种情况,是因为memoize实现对合并的单元格没有适当的约束。
cvss | epss | percentile |
---|---|---|
None | 0.05% | 14.37% |
references
- http://www.openwall.com/lists/oss-security/2024/01/10/2
- https://github.com/haile01/perl_spreadsheet_excel_rce_poc/blob/main/parse_xlsx_bomb.md
- https://lists.debian.org/debian-lts-announce/2024/01/msg00018.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6R7NYWVVZYDZIQC5YEXNHZM6VEE26SJV/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/WNJVC4C5C5V44DNOZ5BHVU53CDXPB2OJ/
- https://metacpan.org/dist/Spreadsheet-ParseXLSX/changes
CVE-2024-24577
description
libgit2 is a portable C implementation of the Git core methods provided as a linkable library with a solid API, allowing to build Git functionality into your application. Using well-crafted inputs to git_index_add
can cause heap corruption that could be leveraged for arbitrary code execution. There is an issue in the has_dir_name
function in src/libgit2/index.c
, which frees an entry that should not be freed. The freed entry is later used and overwritten with potentially bad actor-controlled data leading to controlled heap corruption. Depending on the application that uses libgit2, this could lead to arbitrary code execution. This issue has been patched in version 1.6.5 and 1.7.2.
description
libgit2是Git核心方法的可移植C实现,作为一个具有坚实API的可链接库提供,允许在应用程序中构建Git功能。对“git_index_add”使用精心编制的输入可能会导致堆损坏,而堆损坏可用于执行任意代码。“src/libgit2/index.c”中的“has_dir_name”函数存在问题,该函数释放了一个不应释放的条目。释放的条目稍后会被使用,并被潜在的不良参与者控制的数据覆盖,从而导致受控堆损坏。根据使用libgit2的应用程序的不同,这可能导致任意代码的执行。此问题已在1.6.5和1.7.2版本中进行了修补。
cvss | epss | percentile |
---|---|---|
8.6 HIGH | 0.23% | 60.18% |
references
- https://github.com/libgit2/libgit2/releases/tag/v1.6.5
- https://github.com/libgit2/libgit2/releases/tag/v1.7.2
- https://github.com/libgit2/libgit2/security/advisories/GHSA-j2v7-4f6v-gpg8
- https://lists.debian.org/debian-lts-announce/2024/02/msg00012.html
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4M3P7WIEPXNRLBINQRJFXUSTNKBCHYC7/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7CNDW3PF6NHO7OXNM5GN6WSSGAMA7MZE/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/S635BGHHZUMRPI7QOXOJ45QHDD5FFZ3S/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/Z6MXOX7I43OWNN7R6M54XLG6U5RXY244/
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZGNHOEE2RBLH7KCJUPUNYG4CDTW4HTBT/
CVE-2024-25711
description
diffoscope before 256 allows directory traversal via an embedded filename in a GPG file. Contents of any file, such as ../.ssh/id_rsa, may be disclosed to an attacker. This occurs because the value of the gpg –use-embedded-filenames option is trusted.
description
diffscope在256之前允许通过GPG文件中嵌入的文件名进行目录遍历。任何文件的内容,如../。ssh/id_rsa)可能被泄露给攻击者。之所以会出现这种情况,是因为gpg–使用嵌入式文件名选项的值是可信的。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 12.26% |
references
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OUNBANAWD6TZH2NRRV4YUIAXEHLUJQ47/
- https://salsa.debian.org/reproducible-builds/diffoscope/-/commit/dfed769904c27d66a14a5903823d9c8c5aae860e
- https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/361
CVE-2024-25760
description
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
description
拒绝不要使用此候选号码。咨询ID:无。原因:此候选人已被其CNA撤回。进一步调查表明,这不是一个安全问题。注:无。
cvss | epss | percentile |
---|---|---|
None | None | None |
CVE-2024-26484
description
** DISPUTED ** A stored cross-site scripting (XSS) vulnerability in the Edit Content Layout module of Kirby CMS v4.1.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Link field. NOTE: the vendors position is that this issue did not affect any version of Kirby CMS. The only effect was on the trykirby.com demo site, which is not customer-controlled.
description
争议Kirby CMS v4.1.0的编辑内容布局模块中存在存储的跨站点脚本(XSS)漏洞,攻击者可以通过向链接字段中注入特制的有效负载来执行任意web脚本或HTML。注:供应商的立场是,这个问题没有影响任何版本的Kirby CMS。唯一的影响是在trykirby.com演示网站上,该网站不受客户控制。
cvss | epss | percentile |
---|---|---|
None | 0.04% | 6.87% |