🚨 CVE-2024-53148
In the Linux kernel, the following vulnerability has been resolved:
comedi: Flush partial mappings in error case
If some remap_pfn_range() calls succeeded before one failed, we still have
buffer pages mapped into the userspace page tables when we drop the buffer
reference with comedi_buf_map_put(bm). The userspace mappings are only
cleaned up later in the mmap error path.
Fix it by explicitly flushing all mappings in our VMA on the error path.
See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in
error case").
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
comedi: Flush partial mappings in error case
If some remap_pfn_range() calls succeeded before one failed, we still have
buffer pages mapped into the userspace page tables when we drop the buffer
reference with comedi_buf_map_put(bm). The userspace mappings are only
cleaned up later in the mmap error path.
Fix it by explicitly flushing all mappings in our VMA on the error path.
See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in
error case").
🎖@cveNotify
🚨 CVE-2024-53152
In the Linux kernel, the following vulnerability has been resolved:
PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()
Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF
deinit notify function pci_epc_deinit_notify() are called during the
execution of pex_ep_event_pex_rst_assert() i.e., when the host has asserted
PERST#. But quickly after this step, refclk will also be disabled by the
host.
All of the tegra194 endpoint SoCs supported as of now depend on the refclk
from the host for keeping the controller operational. Due to this
limitation, any access to the hardware registers in the absence of refclk
will result in a whole endpoint crash. Unfortunately, most of the
controller cleanups require accessing the hardware registers (like eDMA
cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup
functions can cause the crash in the endpoint SoC once host asserts PERST#.
One way to address this issue is by generating the refclk in the endpoint
itself and not depending on the host. But that is not always possible as
some of the endpoint designs do require the endpoint to consume refclk from
the host.
Thus, fix this crash by moving the controller cleanups to the start of
the pex_ep_event_pex_rst_deassert() function. This function is called
whenever the host has deasserted PERST# and it is guaranteed that the
refclk would be active at this point. So at the start of this function
(after enabling resources) the controller cleanup can be performed. Once
finished, rest of the code execution for PERST# deassert can continue as
usual.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()
Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF
deinit notify function pci_epc_deinit_notify() are called during the
execution of pex_ep_event_pex_rst_assert() i.e., when the host has asserted
PERST#. But quickly after this step, refclk will also be disabled by the
host.
All of the tegra194 endpoint SoCs supported as of now depend on the refclk
from the host for keeping the controller operational. Due to this
limitation, any access to the hardware registers in the absence of refclk
will result in a whole endpoint crash. Unfortunately, most of the
controller cleanups require accessing the hardware registers (like eDMA
cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup
functions can cause the crash in the endpoint SoC once host asserts PERST#.
One way to address this issue is by generating the refclk in the endpoint
itself and not depending on the host. But that is not always possible as
some of the endpoint designs do require the endpoint to consume refclk from
the host.
Thus, fix this crash by moving the controller cleanups to the start of
the pex_ep_event_pex_rst_deassert() function. This function is called
whenever the host has deasserted PERST# and it is guaranteed that the
refclk would be active at this point. So at the start of this function
(after enabling resources) the controller cleanup can be performed. Once
finished, rest of the code execution for PERST# deassert can continue as
usual.
🎖@cveNotify
🚨 CVE-2024-53153
In the Linux kernel, the following vulnerability has been resolved:
PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()
Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF
deinit notify function pci_epc_deinit_notify() are called during the
execution of qcom_pcie_perst_assert() i.e., when the host has asserted
PERST#. But quickly after this step, refclk will also be disabled by the
host.
All of the Qcom endpoint SoCs supported as of now depend on the refclk from
the host for keeping the controller operational. Due to this limitation,
any access to the hardware registers in the absence of refclk will result
in a whole endpoint crash. Unfortunately, most of the controller cleanups
require accessing the hardware registers (like eDMA cleanup performed in
dw_pcie_ep_cleanup(), powering down MHI EPF etc...). So these cleanup
functions are currently causing the crash in the endpoint SoC once host
asserts PERST#.
One way to address this issue is by generating the refclk in the endpoint
itself and not depending on the host. But that is not always possible as
some of the endpoint designs do require the endpoint to consume refclk from
the host (as I was told by the Qcom engineers).
Thus, fix this crash by moving the controller cleanups to the start of
the qcom_pcie_perst_deassert() function. qcom_pcie_perst_deassert() is
called whenever the host has deasserted PERST# and it is guaranteed that
the refclk would be active at this point. So at the start of this function
(after enabling resources), the controller cleanup can be performed. Once
finished, rest of the code execution for PERST# deassert can continue as
usual.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()
Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF
deinit notify function pci_epc_deinit_notify() are called during the
execution of qcom_pcie_perst_assert() i.e., when the host has asserted
PERST#. But quickly after this step, refclk will also be disabled by the
host.
All of the Qcom endpoint SoCs supported as of now depend on the refclk from
the host for keeping the controller operational. Due to this limitation,
any access to the hardware registers in the absence of refclk will result
in a whole endpoint crash. Unfortunately, most of the controller cleanups
require accessing the hardware registers (like eDMA cleanup performed in
dw_pcie_ep_cleanup(), powering down MHI EPF etc...). So these cleanup
functions are currently causing the crash in the endpoint SoC once host
asserts PERST#.
One way to address this issue is by generating the refclk in the endpoint
itself and not depending on the host. But that is not always possible as
some of the endpoint designs do require the endpoint to consume refclk from
the host (as I was told by the Qcom engineers).
Thus, fix this crash by moving the controller cleanups to the start of
the qcom_pcie_perst_deassert() function. qcom_pcie_perst_deassert() is
called whenever the host has deasserted PERST# and it is guaranteed that
the refclk would be active at this point. So at the start of this function
(after enabling resources), the controller cleanup can be performed. Once
finished, rest of the code execution for PERST# deassert can continue as
usual.
🎖@cveNotify
🔥1
🚨 CVE-2024-50216
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix finding a last resort AG in xfs_filestream_pick_ag
When the main loop in xfs_filestream_pick_ag fails to find a suitable
AG it tries to just pick the online AG. But the loop for that uses
args->pag as loop iterator while the later code expects pag to be
set. Fix this by reusing the max_pag case for this last resort, and
also add a check for impossible case of no AG just to make sure that
the uninitialized pag doesn't even escape in theory.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix finding a last resort AG in xfs_filestream_pick_ag
When the main loop in xfs_filestream_pick_ag fails to find a suitable
AG it tries to just pick the online AG. But the loop for that uses
args->pag as loop iterator while the later code expects pag to be
set. Fix this by reusing the max_pag case for this last resort, and
also add a check for impossible case of no AG just to make sure that
the uninitialized pag doesn't even escape in theory.
🎖@cveNotify
🚨 CVE-2024-50218
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow
Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two
reasons for this: first, the parameter value passed is greater than
ocfs2_max_inline_data_with_xattr, second, the start and end parameters of
ocfs2_truncate_inline are "unsigned int".
So, we need to add a sanity check for byte_start and byte_len right before
ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater
than ocfs2_max_inline_data_with_xattr return -EINVAL.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow
Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two
reasons for this: first, the parameter value passed is greater than
ocfs2_max_inline_data_with_xattr, second, the start and end parameters of
ocfs2_truncate_inline are "unsigned int".
So, we need to add a sanity check for byte_start and byte_len right before
ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater
than ocfs2_max_inline_data_with_xattr return -EINVAL.
🎖@cveNotify
🚨 CVE-2024-50289
In the Linux kernel, the following vulnerability has been resolved:
media: av7110: fix a spectre vulnerability
As warned by smatch:
drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap)
There is a spectre-related vulnerability at the code. Fix it.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
media: av7110: fix a spectre vulnerability
As warned by smatch:
drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap)
There is a spectre-related vulnerability at the code. Fix it.
🎖@cveNotify
🚨 CVE-2024-50295
In the Linux kernel, the following vulnerability has been resolved:
net: arc: fix the device for dma_map_single/dma_unmap_single
The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent
which has dma_mask, ndev->dev.parent is just pdev->dev.
Or it would cause the following issue:
[ 39.933526] ------------[ cut here ]------------
[ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net: arc: fix the device for dma_map_single/dma_unmap_single
The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent
which has dma_mask, ndev->dev.parent is just pdev->dev.
Or it would cause the following issue:
[ 39.933526] ------------[ cut here ]------------
[ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8
🎖@cveNotify
🚨 CVE-2024-42330
The HttpRequest object allows to get the HTTP headers from the server's response after sending the request. The problem is that the returned strings are created directly from the data returned by the server and are not correctly encoded for JavaScript. This allows to create internal strings that can be used to access hidden properties of objects.
🎖@cveNotify
The HttpRequest object allows to get the HTTP headers from the server's response after sending the request. The problem is that the returned strings are created directly from the data returned by the server and are not correctly encoded for JavaScript. This allows to create internal strings that can be used to access hidden properties of objects.
🎖@cveNotify
🚨 CVE-2024-42331
In the src/libs/zbxembed/browser.c file, the es_browser_ctor method retrieves a heap pointer from the Duktape JavaScript engine. This heap pointer is subsequently utilized by the browser_push_error method in the src/libs/zbxembed/browser_error.c file. A use-after-free bug can occur at this stage if the wd->browser heap pointer is freed by garbage collection.
🎖@cveNotify
In the src/libs/zbxembed/browser.c file, the es_browser_ctor method retrieves a heap pointer from the Duktape JavaScript engine. This heap pointer is subsequently utilized by the browser_push_error method in the src/libs/zbxembed/browser_error.c file. A use-after-free bug can occur at this stage if the wd->browser heap pointer is freed by garbage collection.
🎖@cveNotify
🚨 CVE-2024-42332
The researcher is showing that due to the way the SNMP trap log is parsed, an attacker can craft an SNMP trap with additional lines of information and have forged data show in the Zabbix UI. This attack requires SNMP auth to be off and/or the attacker to know the community/auth details. The attack requires an SNMP item to be configured as text on the target host.
🎖@cveNotify
The researcher is showing that due to the way the SNMP trap log is parsed, an attacker can craft an SNMP trap with additional lines of information and have forged data show in the Zabbix UI. This attack requires SNMP auth to be off and/or the attacker to know the community/auth details. The attack requires an SNMP item to be configured as text on the target host.
🎖@cveNotify
🚨 CVE-2024-42333
The researcher is showing that it is possible to leak a small amount of Zabbix Server memory using an out of bounds read in src/libs/zbxmedia/email.c
🎖@cveNotify
The researcher is showing that it is possible to leak a small amount of Zabbix Server memory using an out of bounds read in src/libs/zbxmedia/email.c
🎖@cveNotify
🔥1
🚨 CVE-2024-36464
When exporting media types, the password is exported in the YAML in plain text. This appears to be a best practices type issue and may have no actual impact. The user would need to have permissions to access the media types and therefore would be expected to have access to these passwords.
🎖@cveNotify
When exporting media types, the password is exported in the YAML in plain text. This appears to be a best practices type issue and may have no actual impact. The user would need to have permissions to access the media types and therefore would be expected to have access to these passwords.
🎖@cveNotify
🚨 CVE-2024-36466
A bug in the code allows an attacker to sign a forged zbx_session cookie, which then allows them to sign in with admin permissions.
🎖@cveNotify
A bug in the code allows an attacker to sign a forged zbx_session cookie, which then allows them to sign in with admin permissions.
🎖@cveNotify
🚨 CVE-2024-36465
A low privilege (regular) Zabbix user with API access can use SQL injection vulnerability in include/classes/api/CApiService.php to execute arbitrary SQL commands via the groupBy parameter.
🎖@cveNotify
A low privilege (regular) Zabbix user with API access can use SQL injection vulnerability in include/classes/api/CApiService.php to execute arbitrary SQL commands via the groupBy parameter.
🎖@cveNotify
🚨 CVE-2024-36469
Execution time for an unsuccessful login differs when using a non-existing username compared to using an existing one.
🎖@cveNotify
Execution time for an unsuccessful login differs when using a non-existing username compared to using an existing one.
🎖@cveNotify
🚨 CVE-2024-42325
Zabbix API user.get returns all users that share common group with the calling user. This includes media and other information, such as login attempts, etc.
🎖@cveNotify
Zabbix API user.get returns all users that share common group with the calling user. This includes media and other information, such as login attempts, etc.
🎖@cveNotify
👍1
🚨 CVE-2024-45699
The endpoint /zabbix.php?action=export.valuemaps suffers from a Cross-Site Scripting vulnerability via the backurl parameter. This is caused by the reflection of user-supplied data without appropriate HTML escaping or output encoding. As a result, a JavaScript payload may be injected into the above endpoint causing it to be executed within the context of the victim's browser.
🎖@cveNotify
The endpoint /zabbix.php?action=export.valuemaps suffers from a Cross-Site Scripting vulnerability via the backurl parameter. This is caused by the reflection of user-supplied data without appropriate HTML escaping or output encoding. As a result, a JavaScript payload may be injected into the above endpoint causing it to be executed within the context of the victim's browser.
🎖@cveNotify
👍1
🚨 CVE-2025-11274
A vulnerability was determined in Open Asset Import Library Assimp 6.0.2. Affected is the function Q3DImporter::InternReadFile of the file assimp/code/AssetLib/Q3D/Q3DLoader.cpp. This manipulation causes allocation of resources. The attack is restricted to local execution. The exploit has been publicly disclosed and may be utilized.
🎖@cveNotify
A vulnerability was determined in Open Asset Import Library Assimp 6.0.2. Affected is the function Q3DImporter::InternReadFile of the file assimp/code/AssetLib/Q3D/Q3DLoader.cpp. This manipulation causes allocation of resources. The attack is restricted to local execution. The exploit has been publicly disclosed and may be utilized.
🎖@cveNotify
GitHub
Bug: Allocation-Size-Too-Big Error in Q3DImporter::InternReadFile · Issue #6356 · assimp/assimp
Environment OS: Ubuntu 22.04 Compiler: clang 13.0.1 C++ Standard: C++17 Sanitizers: AddressSanitizer (ASan) + UndefinedBehaviorSanitizer (UBSan) Assimp Version: 6.0.2 / master commit 0581ed5 Build ...
🚨 CVE-2025-11275
A vulnerability was identified in Open Asset Import Library Assimp 6.0.2. Affected by this vulnerability is the function ODDLParser::getNextSeparator in the library assimp/contrib/openddlparser/include/openddlparser/OpenDDLParserUtils.h. Such manipulation leads to heap-based buffer overflow. The attack must be carried out locally. The exploit is publicly available and might be used.
🎖@cveNotify
A vulnerability was identified in Open Asset Import Library Assimp 6.0.2. Affected by this vulnerability is the function ODDLParser::getNextSeparator in the library assimp/contrib/openddlparser/include/openddlparser/OpenDDLParserUtils.h. Such manipulation leads to heap-based buffer overflow. The attack must be carried out locally. The exploit is publicly available and might be used.
🎖@cveNotify
GitHub
Bug: Heap-buffer-overflow in ODDLParser::getNextSeparator · Issue #6357 · assimp/assimp
Environment OS: Ubuntu 22.04 Compiler: clang 13.0.1 C++ Standard: C++17 Sanitizers: AddressSanitizer (ASan) + UndefinedBehaviorSanitizer (UBSan) Assimp Version: 6.0.2 / master commit 0581ed5 Build ...
🚨 CVE-2025-11277
A weakness has been identified in Open Asset Import Library Assimp 6.0.2. This affects the function Q3DImporter::InternReadFile of the file assimp/code/AssetLib/Q3D/Q3DLoader.cpp. Executing manipulation can lead to heap-based buffer overflow. The attack needs to be launched locally. The exploit has been made available to the public and could be exploited.
🎖@cveNotify
A weakness has been identified in Open Asset Import Library Assimp 6.0.2. This affects the function Q3DImporter::InternReadFile of the file assimp/code/AssetLib/Q3D/Q3DLoader.cpp. Executing manipulation can lead to heap-based buffer overflow. The attack needs to be launched locally. The exploit has been made available to the public and could be exploited.
🎖@cveNotify
GitHub
Bug: Heap-buffer-overflow in Q3DImporter::InternReadFile · Issue #6358 · assimp/assimp
Environment OS: Ubuntu 22.04 Compiler: clang 13.0.1 C++ Standard: C++17 Sanitizers: AddressSanitizer (ASan) + UndefinedBehaviorSanitizer (UBSan) Assimp Version: 6.0.2 / master commit 0581ed5 Build ...
🚨 CVE-2024-22120
Zabbix server can perform command execution for configured scripts. After command is executed, audit entry is added to "Audit Log". Due to "clientip" field is not sanitized, it is possible to injection SQL into "clientip" and exploit time based blind SQL injection.
🎖@cveNotify
Zabbix server can perform command execution for configured scripts. After command is executed, audit entry is added to "Audit Log". Due to "clientip" field is not sanitized, it is possible to injection SQL into "clientip" and exploit time based blind SQL injection.
🎖@cveNotify