| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
qibfs: fix dentry leak
simple_recursive_removal() drops the pinning references to all positives
in subtree. For the cases when its argument has been kept alive by
the pinning alone that's exactly the right thing to do, but here
the argument comes from dcache lookup, that needs to be balanced by
explicit dput().
Fucked-up-by: Al Viro <viro@zeniv.linux.org.uk> |
| In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix neighbour and rtable leak in smc_ib_find_route()
In smc_ib_find_route(), the neighbour found by neigh_lookup() and rtable
resolved by ip_route_output_flow() are not released or put before return.
It may cause the refcount leak, so fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ieee802154: ca8210: Stop leaking skb's
Upon error the ieee802154_xmit_complete() helper is not called. Only
ieee802154_wake_queue() is called manually. We then leak the skb
structure.
Free the skb structure upon error before returning. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Forcibly leave nested virt when SMM state is toggled
Forcibly leave nested virtualization operation if userspace toggles SMM
state via KVM_SET_VCPU_EVENTS or KVM_SYNC_X86_EVENTS. If userspace
forces the vCPU out of SMM while it's post-VMXON and then injects an SMI,
vmx_enter_smm() will overwrite vmx->nested.smm.vmxon and end up with both
vmxon=false and smm.vmxon=false, but all other nVMX state allocated.
Don't attempt to gracefully handle the transition as (a) most transitions
are nonsencial, e.g. forcing SMM while L2 is running, (b) there isn't
sufficient information to handle all transitions, e.g. SVM wants access
to the SMRAM save state, and (c) KVM_SET_VCPU_EVENTS must precede
KVM_SET_NESTED_STATE during state restore as the latter disallows putting
the vCPU into L2 if SMM is active, and disallows tagging the vCPU as
being post-VMXON in SMM if SMM is not active.
Abuse of KVM_SET_VCPU_EVENTS manifests as a WARN and memory leak in nVMX
due to failure to free vmcs01's shadow VMCS, but the bug goes far beyond
just a memory leak, e.g. toggling SMM on while L2 is active puts the vCPU
in an architecturally impossible state.
WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]
WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656
Modules linked in:
CPU: 1 PID: 3606 Comm: syz-executor725 Not tainted 5.17.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]
RIP: 0010:free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656
Code: <0f> 0b eb b3 e8 8f 4d 9f 00 e9 f7 fe ff ff 48 89 df e8 92 4d 9f 00
Call Trace:
<TASK>
kvm_arch_vcpu_destroy+0x72/0x2f0 arch/x86/kvm/x86.c:11123
kvm_vcpu_destroy arch/x86/kvm/../../../virt/kvm/kvm_main.c:441 [inline]
kvm_destroy_vcpus+0x11f/0x290 arch/x86/kvm/../../../virt/kvm/kvm_main.c:460
kvm_free_vcpus arch/x86/kvm/x86.c:11564 [inline]
kvm_arch_destroy_vm+0x2e8/0x470 arch/x86/kvm/x86.c:11676
kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1217 [inline]
kvm_put_kvm+0x4fa/0xb00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1250
kvm_vm_release+0x3f/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1273
__fput+0x286/0x9f0 fs/file_table.c:311
task_work_run+0xdd/0x1a0 kernel/task_work.c:164
exit_task_work include/linux/task_work.h:32 [inline]
do_exit+0xb29/0x2a30 kernel/exit.c:806
do_group_exit+0xd2/0x2f0 kernel/exit.c:935
get_signal+0x4b0/0x28c0 kernel/signal.c:2862
arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868
handle_signal_work kernel/entry/common.c:148 [inline]
exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207
__syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]
syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300
do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x44/0xae
</TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix kernel crash during resume
Currently during resume, QMI target memory is not properly handled, resulting
in kernel crash in case DMA remap is not supported:
BUG: Bad page state in process kworker/u16:54 pfn:36e80
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x36e80
page dumped because: nonzero _refcount
Call Trace:
bad_page
free_page_is_bad_report
__free_pages_ok
__free_pages
dma_direct_free
dma_free_attrs
ath12k_qmi_free_target_mem_chunk
ath12k_qmi_msg_mem_request_cb
The reason is:
Once ath12k module is loaded, firmware sends memory request to host. In case
DMA remap not supported, ath12k refuses the first request due to failure in
allocating with large segment size:
ath12k_pci 0000:04:00.0: qmi firmware request memory request
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 7077888
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 8454144
ath12k_pci 0000:04:00.0: qmi dma allocation failed (7077888 B type 1), will try later with small size
ath12k_pci 0000:04:00.0: qmi delays mem_request 2
ath12k_pci 0000:04:00.0: qmi firmware request memory request
Later firmware comes back with more but small segments and allocation
succeeds:
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 262144
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288
ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 65536
ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288
Now ath12k is working. If suspend is triggered, firmware will be reloaded
during resume. As same as before, firmware requests two large segments at
first. In ath12k_qmi_msg_mem_request_cb() segment count and size are
assigned:
ab->qmi.mem_seg_count == 2
ab->qmi.target_mem[0].size == 7077888
ab->qmi.target_mem[1].size == 8454144
Then allocation failed like before and ath12k_qmi_free_target_mem_chunk()
is called to free all allocated segments. Note the first segment is skipped
because its v.addr is cleared due to allocation failure:
chunk->v.addr = dma_alloc_coherent()
Also note that this leaks that segment because it has not been freed.
While freeing the second segment, a size of 8454144 is passed to
dma_free_coherent(). However remember that this segment is allocated at
the first time firmware is loaded, before suspend. So its real size is
524288, much smaller than 8454144. As a result kernel found we are freeing
some memory which is in use and thus cras
---truncated--- |
| A Missing Release of Memory after Effective Lifetime vulnerability in the rtlogd process of Juniper Networks Junos OS on MX Series with SPC3 allows an unauthenticated, adjacent attacker to trigger internal events cause ( which can be done by repeated port flaps) to cause a slow memory leak, ultimately leading to a Denial of Service (DoS).
Memory can only be recovered by manually restarting rtlogd process.
The memory usage can be monitored using the below command.
user@host> show system processes extensive | match rtlog
This issue affects Junos OS on MX Series with SPC3 line card:
* from 21.2R3 before 21.2R3-S8,
* from 21.4R2 before 21.4R3-S6,
* from 22.1 before 22.1R3-S5,
* from 22.2 before 22.2R3-S3,
* from 22.3 before 22.3R3-S2,
* from 22.4 before 22.4R3-S1,
* from 23.2 before 23.2R2,
* from 23.4 before 23.4R2. |
| LiteSpeed QUIC (LSQUIC) Library before 4.3.1 has an lsquic_engine_packet_in memory leak. |
| Redis through 8.0.3 allows memory consumption via a multi-bulk command composed of many bulks, sent by an authenticated user. This occurs because the server allocates memory for the command arguments of every bulk, even when the command is skipped because of insufficient permissions. NOTE: this is disputed by the Supplier because abuse of the commands network protocol is not a violation of the Redis Security Model. |
| A vulnerability in the Internet Key Exchange Version 2 (IKEv2) feature of Cisco IOS Software, IOS XE Software, Secure Firewall Adaptive Security Appliance (ASA) Software, and Secure Firewall Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to trigger a memory leak, resulting in a denial of service (DoS) condition.
This vulnerability is due to a lack of proper processing of IKEv2 packets. An attacker could exploit this vulnerability by sending crafted IKEv2 packets to an affected device. In the case of Cisco IOS and IOS XE Software, a successful exploit could allow the attacker to cause the device to reload unexpectedly. In the case of Cisco ASA and FTD Software, a successful exploit could allow the attacker to partially exhaust system memory, causing system instability such as being unable to establish new IKEv2 VPN sessions. A manual reboot of the device is required to recover from this condition. |
| A vulnerability in the Internet Key Exchange Version 2 (IKEv2) module of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Secure Firewall Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to trigger a memory leak, resulting in a denial of service (DoS) condition.
This vulnerability is due to improper parsing of IKEv2 packets. An attacker could exploit this vulnerability by sending a continuous stream of crafted IKEv2 packets to an affected device. A successful exploit could allow the attacker to partially exhaust system memory, causing system instability like being unable to establish new IKEv2 VPN sessions. A manual reboot of the device is required to recover from this condition. |
| A vulnerability in the Internet Key Exchange Version 2 (IKEv2) module of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Secure Firewall Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to trigger a memory leak, resulting in a denial of service (DoS) condition.
This vulnerability is due to improper parsing of IKEv2 packets. An attacker could exploit this vulnerability by sending a continuous stream of crafted IKEv2 packets to an affected device. A successful exploit could allow the attacker to partially exhaust system memory, causing system instability like being unable to establish new IKEv2 VPN sessions. A manual reboot of the device is required to recover from this condition. |
| A vulnerability in the Internet Key Exchange Version 2 (IKEv2) feature of Cisco IOS Software, IOS XE Software, Secure Firewall Adaptive Security Appliance (ASA) Software, and Secure Firewall Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to trigger a memory leak, resulting in a denial of service (DoS) condition.
This vulnerability is due to a lack of proper processing of IKEv2 packets. An attacker could exploit this vulnerability by sending crafted IKEv2 packets to an affected device. In the case of Cisco IOS and IOS XE Software, a successful exploit could allow the attacker to cause the device to reload unexpectedly. In the case of Cisco ASA and FTD Software, a successful exploit could allow the attacker to partially exhaust system memory, causing system instability such as being unable to establish new IKEv2 VPN sessions. A manual reboot of the device is required to recover from this condition. |
| A vulnerability in the DHCP client functionality of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Cisco Secure Firewall Threat Defense (FTD) Software could allow an unauthenticated, adjacent attacker to exhaust available memory.
This vulnerability is due to improper validation of incoming DHCP packets. An attacker could exploit this vulnerability by repeatedly sending crafted DHCPv4 packets to an affected device. A successful exploit could allow the attacker to exhaust available memory, which would affect availability of services and prevent new processes from starting, resulting in a Denial of Service (DoS) condition that would require a manual reboot.
Note: On Cisco Secure FTD Software, this vulnerability does not affect management interfaces. |
| A vulnerability in the management and VPN web servers of the Remote Access SSL VPN feature of Cisco Secure Firewall ASA Software and Secure FTD Software could allow an unauthenticated, remote attacker to cause the device to unexpectedly stop responding, resulting in a DoS condition.
This vulnerability is due to ineffective validation of user-supplied input during the Remote Access SSL VPN authentication process. An attacker could exploit this vulnerability by sending a crafted request to the VPN service on an affected device. A successful exploit could allow the attacker to cause a DoS condition where the device stops responding to Remote Access SSL VPN authentication requests. |
| A vulnerability in the Internet Key Exchange Version 2 (IKEv2) module of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Secure Firewall Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to trigger a memory leak, resulting in a denial of service (DoS) condition.
This vulnerability is due to improper parsing of IKEv2 packets. An attacker could exploit this vulnerability by sending a continuous stream of crafted IKEv2 packets to an affected device. A successful exploit could allow the attacker to partially exhaust system memory, causing system instability like being unable to establish new IKEv2 VPN sessions. A manual reboot of the device is required to recover from this condition. |
| Missing release of memory after effective lifetime in the UEFI OobRasMmbiHandlerDriver module for some Intel(R) reference server platforms may allow a privileged user to enable denial of service via local access. |
| in OpenHarmony v5.0.3 and prior versions allow a local attacker case DOS through missing release of memory. |
| in OpenHarmony v5.0.3 and prior versions allow a local attacker case DOS through missing release of memory. |
| in OpenHarmony v5.0.3 and prior versions allow a local attacker case DOS through missing release of memory. |
| Transient DOS while processing multiple IKEV2 Informational Request to device from IPSEC server with different identifiers. |
