π¨ CVE-2024-0564
A flaw was found in the Linux kernel's memory deduplication mechanism. The max page sharing of Kernel Samepage Merging (KSM), added in Linux kernel version 4.4.0-96.119, can create a side channel. When the attacker and the victim share the same host and the default setting of KSM is "max page sharing=256", it is possible for the attacker to time the unmap to merge with the victim's page. The unmapping time depends on whether it merges with the victim's page and additional physical pages are created beyond the KSM's "max page share". Through these operations, the attacker can leak the victim's page.
π@cveNotify
A flaw was found in the Linux kernel's memory deduplication mechanism. The max page sharing of Kernel Samepage Merging (KSM), added in Linux kernel version 4.4.0-96.119, can create a side channel. When the attacker and the victim share the same host and the default setting of KSM is "max page sharing=256", it is possible for the attacker to time the unmap to merge with the victim's page. The unmapping time depends on whether it merges with the victim's page and additional physical pages are created beyond the KSM's "max page share". Through these operations, the attacker can leak the victim's page.
π@cveNotify
π¨ CVE-2021-23282
Eaton Intelligent Power Manager (IPM) prior to 1.70 is vulnerable to stored Cross site scripting. The
vulnerability exists due to insufficient validation of input from certain resources by the IPM software.
The attacker would need access to the local Subnet and an administrator interaction to compromise
the system
π@cveNotify
Eaton Intelligent Power Manager (IPM) prior to 1.70 is vulnerable to stored Cross site scripting. The
vulnerability exists due to insufficient validation of input from certain resources by the IPM software.
The attacker would need access to the local Subnet and an administrator interaction to compromise
the system
π@cveNotify
π¨ CVE-2022-33861
IPP software versions prior to v1.71 do not sufficiently verify the authenticity of data, in a
way that causes it to accept invalid data.
π@cveNotify
IPP software versions prior to v1.71 do not sufficiently verify the authenticity of data, in a
way that causes it to accept invalid data.
π@cveNotify
π¨ CVE-2022-33862
IPP software prior to v1.71 is vulnerable to default credential vulnerability. This could
lead attackers to identify and access vulnerable systems.
π@cveNotify
IPP software prior to v1.71 is vulnerable to default credential vulnerability. This could
lead attackers to identify and access vulnerable systems.
π@cveNotify
π¨ CVE-2024-11663
A vulnerability classified as critical was found in Codezips E-Commerce Site 1.0. Affected by this vulnerability is an unknown functionality of the file search.php. The manipulation of the argument keywords leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.
π@cveNotify
A vulnerability classified as critical was found in Codezips E-Commerce Site 1.0. Affected by this vulnerability is an unknown functionality of the file search.php. The manipulation of the argument keywords leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.
π@cveNotify
GitHub
Codezips E-commerce Site Using PHP With Source Code V1.0 search.php SQL injection Β· Issue #1 Β· disinroot/CVE
Codezips E-commerce Site Using PHP With Source Code V1.0 search.php SQL injection NAME OF AFFECTED PRODUCT(S) E-commerce Site Using PHP With Source Code Vendor Homepage https://codezips.com/php/e-c...
π¨ CVE-2024-11664
A vulnerability, which was classified as critical, has been found in eNMS up to 4.2. Affected by this issue is the function multiselect_filtering of the file eNMS/controller.py of the component TGZ File Handler. The manipulation leads to path traversal. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The patch is identified as 22b0b443acca740fc83b5544165c1f53eff3f529. It is recommended to apply a patch to fix this issue.
π@cveNotify
A vulnerability, which was classified as critical, has been found in eNMS up to 4.2. Affected by this issue is the function multiselect_filtering of the file eNMS/controller.py of the component TGZ File Handler. The manipulation leads to path traversal. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The patch is identified as 22b0b443acca740fc83b5544165c1f53eff3f529. It is recommended to apply a patch to fix this issue.
π@cveNotify
GitHub
Update controller.py by 0xs1ash Β· Pull Request #419 Β· eNMS-automation/eNMS
Summary
I had previously informed you about the RCE in your admin panel, and you mentioned that it was a feature. I decided to dig deeper into the system and discovered a very critical vulnerabilit...
I had previously informed you about the RCE in your admin panel, and you mentioned that it was a feature. I decided to dig deeper into the system and discovered a very critical vulnerabilit...
π¨ CVE-2024-0022
In multiple functions of CompanionDeviceManagerService.java, there is a possible launch NotificationAccessConfirmationActivity of another user profile due to improper input validation. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.
π@cveNotify
In multiple functions of CompanionDeviceManagerService.java, there is a possible launch NotificationAccessConfirmationActivity of another user profile due to improper input validation. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.
π@cveNotify
π¨ CVE-2024-53068
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()
The scmi_dev->name is released prematurely in __scmi_device_destroy(),
which causes slab-use-after-free when accessing scmi_dev->name in
scmi_bus_notifier(). So move the release of scmi_dev->name to
scmi_device_release() to avoid slab-use-after-free.
| BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec
| Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1
|
| CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1
| Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT)
| Call trace:
| dump_backtrace+0x94/0x114
| show_stack+0x18/0x24
| dump_stack_lvl+0x48/0x60
| print_report+0xf4/0x5b0
| kasan_report+0xa4/0xec
| __asan_report_load1_noabort+0x20/0x2c
| strncmp+0xe4/0xec
| scmi_bus_notifier+0x5c/0x54c
| notifier_call_chain+0xb4/0x31c
| blocking_notifier_call_chain+0x68/0x9c
| bus_notify+0x54/0x78
| device_del+0x1bc/0x840
| device_unregister+0x20/0xb4
| __scmi_device_destroy+0xac/0x280
| scmi_device_destroy+0x94/0xd0
| scmi_chan_setup+0x524/0x750
| scmi_probe+0x7fc/0x1508
| platform_probe+0xc4/0x19c
| really_probe+0x32c/0x99c
| __driver_probe_device+0x15c/0x3c4
| driver_probe_device+0x5c/0x170
| __driver_attach+0x1c8/0x440
| bus_for_each_dev+0xf4/0x178
| driver_attach+0x3c/0x58
| bus_add_driver+0x234/0x4d4
| driver_register+0xf4/0x3c0
| __platform_driver_register+0x60/0x88
| scmi_driver_init+0xb0/0x104
| do_one_initcall+0xb4/0x664
| kernel_init_freeable+0x3c8/0x894
| kernel_init+0x24/0x1e8
| ret_from_fork+0x10/0x20
|
| Allocated by task 1:
| kasan_save_stack+0x2c/0x54
| kasan_set_track+0x2c/0x40
| kasan_save_alloc_info+0x24/0x34
| __kasan_kmalloc+0xa0/0xb8
| __kmalloc_node_track_caller+0x6c/0x104
| kstrdup+0x48/0x84
| kstrdup_const+0x34/0x40
| __scmi_device_create.part.0+0x8c/0x408
| scmi_device_create+0x104/0x370
| scmi_chan_setup+0x2a0/0x750
| scmi_probe+0x7fc/0x1508
| platform_probe+0xc4/0x19c
| really_probe+0x32c/0x99c
| __driver_probe_device+0x15c/0x3c4
| driver_probe_device+0x5c/0x170
| __driver_attach+0x1c8/0x440
| bus_for_each_dev+0xf4/0x178
| driver_attach+0x3c/0x58
| bus_add_driver+0x234/0x4d4
| driver_register+0xf4/0x3c0
| __platform_driver_register+0x60/0x88
| scmi_driver_init+0xb0/0x104
| do_one_initcall+0xb4/0x664
| kernel_init_freeable+0x3c8/0x894
| kernel_init+0x24/0x1e8
| ret_from_fork+0x10/0x20
|
| Freed by task 1:
| kasan_save_stack+0x2c/0x54
| kasan_set_track+0x2c/0x40
| kasan_save_free_info+0x38/0x5c
| __kasan_slab_free+0xe8/0x164
| __kmem_cache_free+0x11c/0x230
| kfree+0x70/0x130
| kfree_const+0x20/0x40
| __scmi_device_destroy+0x70/0x280
| scmi_device_destroy+0x94/0xd0
| scmi_chan_setup+0x524/0x750
| scmi_probe+0x7fc/0x1508
| platform_probe+0xc4/0x19c
| really_probe+0x32c/0x99c
| __driver_probe_device+0x15c/0x3c4
| driver_probe_device+0x5c/0x170
| __driver_attach+0x1c8/0x440
| bus_for_each_dev+0xf4/0x178
| driver_attach+0x3c/0x58
| bus_add_driver+0x234/0x4d4
| driver_register+0xf4/0x3c0
| __platform_driver_register+0x60/0x88
| scmi_driver_init+0xb0/0x104
| do_one_initcall+0xb4/0x664
| kernel_init_freeable+0x3c8/0x894
| kernel_init+0x24/0x1e8
| ret_from_fork+0x10/0x20
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()
The scmi_dev->name is released prematurely in __scmi_device_destroy(),
which causes slab-use-after-free when accessing scmi_dev->name in
scmi_bus_notifier(). So move the release of scmi_dev->name to
scmi_device_release() to avoid slab-use-after-free.
| BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec
| Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1
|
| CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1
| Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT)
| Call trace:
| dump_backtrace+0x94/0x114
| show_stack+0x18/0x24
| dump_stack_lvl+0x48/0x60
| print_report+0xf4/0x5b0
| kasan_report+0xa4/0xec
| __asan_report_load1_noabort+0x20/0x2c
| strncmp+0xe4/0xec
| scmi_bus_notifier+0x5c/0x54c
| notifier_call_chain+0xb4/0x31c
| blocking_notifier_call_chain+0x68/0x9c
| bus_notify+0x54/0x78
| device_del+0x1bc/0x840
| device_unregister+0x20/0xb4
| __scmi_device_destroy+0xac/0x280
| scmi_device_destroy+0x94/0xd0
| scmi_chan_setup+0x524/0x750
| scmi_probe+0x7fc/0x1508
| platform_probe+0xc4/0x19c
| really_probe+0x32c/0x99c
| __driver_probe_device+0x15c/0x3c4
| driver_probe_device+0x5c/0x170
| __driver_attach+0x1c8/0x440
| bus_for_each_dev+0xf4/0x178
| driver_attach+0x3c/0x58
| bus_add_driver+0x234/0x4d4
| driver_register+0xf4/0x3c0
| __platform_driver_register+0x60/0x88
| scmi_driver_init+0xb0/0x104
| do_one_initcall+0xb4/0x664
| kernel_init_freeable+0x3c8/0x894
| kernel_init+0x24/0x1e8
| ret_from_fork+0x10/0x20
|
| Allocated by task 1:
| kasan_save_stack+0x2c/0x54
| kasan_set_track+0x2c/0x40
| kasan_save_alloc_info+0x24/0x34
| __kasan_kmalloc+0xa0/0xb8
| __kmalloc_node_track_caller+0x6c/0x104
| kstrdup+0x48/0x84
| kstrdup_const+0x34/0x40
| __scmi_device_create.part.0+0x8c/0x408
| scmi_device_create+0x104/0x370
| scmi_chan_setup+0x2a0/0x750
| scmi_probe+0x7fc/0x1508
| platform_probe+0xc4/0x19c
| really_probe+0x32c/0x99c
| __driver_probe_device+0x15c/0x3c4
| driver_probe_device+0x5c/0x170
| __driver_attach+0x1c8/0x440
| bus_for_each_dev+0xf4/0x178
| driver_attach+0x3c/0x58
| bus_add_driver+0x234/0x4d4
| driver_register+0xf4/0x3c0
| __platform_driver_register+0x60/0x88
| scmi_driver_init+0xb0/0x104
| do_one_initcall+0xb4/0x664
| kernel_init_freeable+0x3c8/0x894
| kernel_init+0x24/0x1e8
| ret_from_fork+0x10/0x20
|
| Freed by task 1:
| kasan_save_stack+0x2c/0x54
| kasan_set_track+0x2c/0x40
| kasan_save_free_info+0x38/0x5c
| __kasan_slab_free+0xe8/0x164
| __kmem_cache_free+0x11c/0x230
| kfree+0x70/0x130
| kfree_const+0x20/0x40
| __scmi_device_destroy+0x70/0x280
| scmi_device_destroy+0x94/0xd0
| scmi_chan_setup+0x524/0x750
| scmi_probe+0x7fc/0x1508
| platform_probe+0xc4/0x19c
| really_probe+0x32c/0x99c
| __driver_probe_device+0x15c/0x3c4
| driver_probe_device+0x5c/0x170
| __driver_attach+0x1c8/0x440
| bus_for_each_dev+0xf4/0x178
| driver_attach+0x3c/0x58
| bus_add_driver+0x234/0x4d4
| driver_register+0xf4/0x3c0
| __platform_driver_register+0x60/0x88
| scmi_driver_init+0xb0/0x104
| do_one_initcall+0xb4/0x664
| kernel_init_freeable+0x3c8/0x894
| kernel_init+0x24/0x1e8
| ret_from_fork+0x10/0x20
π@cveNotify
π¨ CVE-2024-53074
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: don't leak a link on AP removal
Release the link mapping resource in AP removal. This impacted devices
that do not support the MLD API (9260 and down).
On those devices, we couldn't start the AP again after the AP has been
already started and stopped.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: don't leak a link on AP removal
Release the link mapping resource in AP removal. This impacted devices
that do not support the MLD API (9260 and down).
On those devices, we couldn't start the AP again after the AP has been
already started and stopped.
π@cveNotify
π¨ CVE-2024-53075
In the Linux kernel, the following vulnerability has been resolved:
riscv: Prevent a bad reference count on CPU nodes
When populating cache leaves we previously fetched the CPU device node
at the very beginning. But when ACPI is enabled we go through a
specific branch which returns early and does not call 'of_node_put' for
the node that was acquired.
Since we are not using a CPU device node for the ACPI code anyways, we
can simply move the initialization of it just passed the ACPI block, and
we are guaranteed to have an 'of_node_put' call for the acquired node.
This prevents a bad reference count of the CPU device node.
Moreover, the previous function did not check for errors when acquiring
the device node, so a return -ENOENT has been added for that case.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
riscv: Prevent a bad reference count on CPU nodes
When populating cache leaves we previously fetched the CPU device node
at the very beginning. But when ACPI is enabled we go through a
specific branch which returns early and does not call 'of_node_put' for
the node that was acquired.
Since we are not using a CPU device node for the ACPI code anyways, we
can simply move the initialization of it just passed the ACPI block, and
we are guaranteed to have an 'of_node_put' call for the acquired node.
This prevents a bad reference count of the CPU device node.
Moreover, the previous function did not check for errors when acquiring
the device node, so a return -ENOENT has been added for that case.
π@cveNotify
π¨ CVE-2024-53088
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix race condition by adding filter's intermediate sync state
Fix a race condition in the i40e driver that leads to MAC/VLAN filters
becoming corrupted and leaking. Address the issue that occurs under
heavy load when multiple threads are concurrently modifying MAC/VLAN
filters by setting mac and port VLAN.
1. Thread T0 allocates a filter in i40e_add_filter() within
i40e_ndo_set_vf_port_vlan().
2. Thread T1 concurrently frees the filter in __i40e_del_filter() within
i40e_ndo_set_vf_mac().
3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which
refers to the already freed filter memory, causing corruption.
Reproduction steps:
1. Spawn multiple VFs.
2. Apply a concurrent heavy load by running parallel operations to change
MAC addresses on the VFs and change port VLANs on the host.
3. Observe errors in dmesg:
"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX,
please set promiscuous on manually for VF XX".
Exact code for stable reproduction Intel can't open-source now.
The fix involves implementing a new intermediate filter state,
I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.
These filters cannot be deleted from the hash list directly but
must be removed using the full process.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix race condition by adding filter's intermediate sync state
Fix a race condition in the i40e driver that leads to MAC/VLAN filters
becoming corrupted and leaking. Address the issue that occurs under
heavy load when multiple threads are concurrently modifying MAC/VLAN
filters by setting mac and port VLAN.
1. Thread T0 allocates a filter in i40e_add_filter() within
i40e_ndo_set_vf_port_vlan().
2. Thread T1 concurrently frees the filter in __i40e_del_filter() within
i40e_ndo_set_vf_mac().
3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which
refers to the already freed filter memory, causing corruption.
Reproduction steps:
1. Spawn multiple VFs.
2. Apply a concurrent heavy load by running parallel operations to change
MAC addresses on the VFs and change port VLANs on the host.
3. Observe errors in dmesg:
"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX,
please set promiscuous on manually for VF XX".
Exact code for stable reproduction Intel can't open-source now.
The fix involves implementing a new intermediate filter state,
I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.
These filters cannot be deleted from the hash list directly but
must be removed using the full process.
π@cveNotify
π¨ CVE-2023-5989
An Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Uyumsoft Information System and Technologies' LioXERP allows an authenticated user to execute Stored XSS.
This issue affects LioXERP: before v.146.
π@cveNotify
An Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Uyumsoft Information System and Technologies' LioXERP allows an authenticated user to execute Stored XSS.
This issue affects LioXERP: before v.146.
π@cveNotify
π¨ CVE-2023-4671
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Talent Software ECOP allows Command Line Execution through SQL Injection.This issue affects ECOP: before 32255.
π@cveNotify
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Talent Software ECOP allows Command Line Execution through SQL Injection.This issue affects ECOP: before 32255.
π@cveNotify
π¨ CVE-2023-51633
Centreon sysName Cross-Site Scripting Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Centreon. User interaction is required to exploit this vulnerability.
The specific flaw exists within the processing of the sysName OID in SNMP. The issue results from the lack of proper validation of user-supplied data, which can lead to the injection of an arbitrary script. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-20731.
π@cveNotify
Centreon sysName Cross-Site Scripting Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Centreon. User interaction is required to exploit this vulnerability.
The specific flaw exists within the processing of the sysName OID in SNMP. The issue results from the lack of proper validation of user-supplied data, which can lead to the injection of an arbitrary script. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-20731.
π@cveNotify
Zerodayinitiative
ZDI-24-416
Centreon sysName Cross-Site Scripting Remote Code Execution Vulnerability
π¨ CVE-2024-52392
Cross-Site Request Forgery (CSRF) vulnerability in W3speedster W3SPEEDSTER.This issue affects W3SPEEDSTER: from n/a through 7.25.
π@cveNotify
Cross-Site Request Forgery (CSRF) vulnerability in W3speedster W3SPEEDSTER.This issue affects W3SPEEDSTER: from n/a through 7.25.
π@cveNotify
Patchstack
WordPress W3SPEEDSTER plugin <= 7.25 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack
Hand curated, verified and enriched vulnerability information by Patchstack security experts. Find all WordPress plugin, theme and core security issues.
π¨ CVE-2023-51625
D-Link DCS-8300LHV2 ONVIF SetSystemDateAndTime Command Injection Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of D-Link DCS-8300LHV2 IP cameras. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed.
The specific flaw exists within the implementation of the ONVIF API, which listens on TCP port 80. When parsing the sch:TZ XML element, the process does not properly validate a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-21319.
π@cveNotify
D-Link DCS-8300LHV2 ONVIF SetSystemDateAndTime Command Injection Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of D-Link DCS-8300LHV2 IP cameras. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed.
The specific flaw exists within the implementation of the ONVIF API, which listens on TCP port 80. When parsing the sch:TZ XML element, the process does not properly validate a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-21319.
π@cveNotify
π¨ CVE-2023-51626
D-Link DCS-8300LHV2 RTSP ValidateAuthorizationHeader Username Stack-Based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of D-Link DCS-8300LHV2 IP cameras. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the handling of the Authorization header by the RTSP server, which listens on TCP port 554. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-21320.
π@cveNotify
D-Link DCS-8300LHV2 RTSP ValidateAuthorizationHeader Username Stack-Based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of D-Link DCS-8300LHV2 IP cameras. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the handling of the Authorization header by the RTSP server, which listens on TCP port 554. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-21320.
π@cveNotify
π¨ CVE-2024-27312
Zohocorp ManageEngine PAM360 version 6601 is vulnerable to authorization vulnerability which allows a low-privileged user to perform admin actions.
Note: This vulnerability affects only the PAM360 6600 version. No other versions are applicable to this vulnerability.
π@cveNotify
Zohocorp ManageEngine PAM360 version 6601 is vulnerable to authorization vulnerability which allows a low-privileged user to perform admin actions.
Note: This vulnerability affects only the PAM360 6600 version. No other versions are applicable to this vulnerability.
π@cveNotify
ManageEngine PAM360
Privileged access management (PAM) solution | ManageEngine PAM360
Comprehensive privileged access management solution for uncompromising enterprise IT security. Achieve complete privileged access protection for your IT infrastructure systems, irrespective of where they resideβon-premises or in the cloud. Get your 30-dayβ¦
π¨ CVE-2024-50066
In the Linux kernel, the following vulnerability has been resolved:
mm/mremap: fix move_normal_pmd/retract_page_tables race
In mremap(), move_page_tables() looks at the type of the PMD entry and the
specified address range to figure out by which method the next chunk of
page table entries should be moved.
At that point, the mmap_lock is held in write mode, but no rmap locks are
held yet. For PMD entries that point to page tables and are fully covered
by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called,
which first takes rmap locks, then does move_normal_pmd().
move_normal_pmd() takes the necessary page table locks at source and
destination, then moves an entire page table from the source to the
destination.
The problem is: The rmap locks, which protect against concurrent page
table removal by retract_page_tables() in the THP code, are only taken
after the PMD entry has been read and it has been decided how to move it.
So we can race as follows (with two processes that have mappings of the
same tmpfs file that is stored on a tmpfs mount with huge=advise); note
that process A accesses page tables through the MM while process B does it
through the file rmap:
process A process B
========= =========
mremap
mremap_to
move_vma
move_page_tables
get_old_pmd
alloc_new_pmd
*** PREEMPT ***
madvise(MADV_COLLAPSE)
do_madvise
madvise_walk_vmas
madvise_vma_behavior
madvise_collapse
hpage_collapse_scan_file
collapse_file
retract_page_tables
i_mmap_lock_read(mapping)
pmdp_collapse_flush
i_mmap_unlock_read(mapping)
move_pgt_entry(NORMAL_PMD, ...)
take_rmap_locks
move_normal_pmd
drop_rmap_locks
When this happens, move_normal_pmd() can end up creating bogus PMD entries
in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect
depends on arch-specific and machine-specific details; on x86, you can end
up with physical page 0 mapped as a page table, which is likely
exploitable for user->kernel privilege escalation.
Fix the race by letting process B recheck that the PMD still points to a
page table after the rmap locks have been taken. Otherwise, we bail and
let the caller fall back to the PTE-level copying path, which will then
bail immediately at the pmd_none() check.
Bug reachability: Reaching this bug requires that you can create
shmem/file THP mappings - anonymous THP uses different code that doesn't
zap stuff under rmap locks. File THP is gated on an experimental config
flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need
shmem THP to hit this bug. As far as I know, getting shmem THP normally
requires that you can mount your own tmpfs with the right mount flags,
which would require creating your own user+mount namespace; though I don't
know if some distros maybe enable shmem THP by default or something like
that.
Bug impact: This issue can likely be used for user->kernel privilege
escalation when it is reachable.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
mm/mremap: fix move_normal_pmd/retract_page_tables race
In mremap(), move_page_tables() looks at the type of the PMD entry and the
specified address range to figure out by which method the next chunk of
page table entries should be moved.
At that point, the mmap_lock is held in write mode, but no rmap locks are
held yet. For PMD entries that point to page tables and are fully covered
by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called,
which first takes rmap locks, then does move_normal_pmd().
move_normal_pmd() takes the necessary page table locks at source and
destination, then moves an entire page table from the source to the
destination.
The problem is: The rmap locks, which protect against concurrent page
table removal by retract_page_tables() in the THP code, are only taken
after the PMD entry has been read and it has been decided how to move it.
So we can race as follows (with two processes that have mappings of the
same tmpfs file that is stored on a tmpfs mount with huge=advise); note
that process A accesses page tables through the MM while process B does it
through the file rmap:
process A process B
========= =========
mremap
mremap_to
move_vma
move_page_tables
get_old_pmd
alloc_new_pmd
*** PREEMPT ***
madvise(MADV_COLLAPSE)
do_madvise
madvise_walk_vmas
madvise_vma_behavior
madvise_collapse
hpage_collapse_scan_file
collapse_file
retract_page_tables
i_mmap_lock_read(mapping)
pmdp_collapse_flush
i_mmap_unlock_read(mapping)
move_pgt_entry(NORMAL_PMD, ...)
take_rmap_locks
move_normal_pmd
drop_rmap_locks
When this happens, move_normal_pmd() can end up creating bogus PMD entries
in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect
depends on arch-specific and machine-specific details; on x86, you can end
up with physical page 0 mapped as a page table, which is likely
exploitable for user->kernel privilege escalation.
Fix the race by letting process B recheck that the PMD still points to a
page table after the rmap locks have been taken. Otherwise, we bail and
let the caller fall back to the PTE-level copying path, which will then
bail immediately at the pmd_none() check.
Bug reachability: Reaching this bug requires that you can create
shmem/file THP mappings - anonymous THP uses different code that doesn't
zap stuff under rmap locks. File THP is gated on an experimental config
flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need
shmem THP to hit this bug. As far as I know, getting shmem THP normally
requires that you can mount your own tmpfs with the right mount flags,
which would require creating your own user+mount namespace; though I don't
know if some distros maybe enable shmem THP by default or something like
that.
Bug impact: This issue can likely be used for user->kernel privilege
escalation when it is reachable.
π@cveNotify
π¨ CVE-2024-7130
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Kion Computer KION Exchange Programs Software allows Reflected XSS.This issue affects KION Exchange Programs Software: before 1.21.9092.29966.
π@cveNotify
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Kion Computer KION Exchange Programs Software allows Reflected XSS.This issue affects KION Exchange Programs Software: before 1.21.9092.29966.
π@cveNotify
π¨ CVE-2024-11670
Incorrect authorization in the permission validation component of Devolutions Remote Desktop Manager 2024.2.21 and earlier on Windows allows a malicious authenticated user to bypass the "View Password" permission via specific actions.
π@cveNotify
Incorrect authorization in the permission validation component of Devolutions Remote Desktop Manager 2024.2.21 and earlier on Windows allows a malicious authenticated user to bypass the "View Password" permission via specific actions.
π@cveNotify
Devolutions
Devolutions