๐จ CVE-2025-60299
Novel-Plus with 5.2.0 was discovered to contain a Stored Cross-Site Scripting (XSS) vulnerability via the /book/addCommentReply endpoint. An authenticated user can inject malicious JavaScript through the replyContent parameter when replying to a book comment. The payload is stored in the database and is executed in other usersโ browsers when they view the affected comment thread.
๐@cveNotify
Novel-Plus with 5.2.0 was discovered to contain a Stored Cross-Site Scripting (XSS) vulnerability via the /book/addCommentReply endpoint. An authenticated user can inject malicious JavaScript through the replyContent parameter when replying to a book comment. The payload is stored in the database and is executed in other usersโ browsers when they view the affected comment thread.
๐@cveNotify
GitHub
GitHub - 201206030/novel-plus: novel-plus ๆฏไธไธชๅค็ซฏ๏ผPCใWAP๏ผ้
่ฏป ใๅ่ฝๅฎๅ็ๅฐ่ฏด CMS ็ณป็ปใๅ
ๆฌๅฐ่ฏดๆจ่ใๅฐ่ฏดๆฃ็ดขใๅฐ่ฏดๆ่กใๅฐ่ฏด้
่ฏปใๅฐ่ฏดไนฆๆถใๅฐ่ฏด่ฏ่ฎบใๅฐ่ฏด็ฌ่ซใไผๅไธญๅฟใไฝๅฎถไธๅบใๅ
ๅผ่ฎข้
ใๆฐ้ปๅๅธ็ญๅ่ฝใ
novel-plus ๆฏไธไธชๅค็ซฏ๏ผPCใWAP๏ผ้
่ฏป ใๅ่ฝๅฎๅ็ๅฐ่ฏด CMS ็ณป็ปใๅ
ๆฌๅฐ่ฏดๆจ่ใๅฐ่ฏดๆฃ็ดขใๅฐ่ฏดๆ่กใๅฐ่ฏด้
่ฏปใๅฐ่ฏดไนฆๆถใๅฐ่ฏด่ฏ่ฎบใๅฐ่ฏด็ฌ่ซใไผๅไธญๅฟใไฝๅฎถไธๅบใๅ
ๅผ่ฎข้
ใๆฐ้ปๅๅธ็ญๅ่ฝใ - 201206030/novel-plus
๐ฅ1
๐จ CVE-2024-53240
In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: fix crash when removing device
When removing a netfront device directly after a suspend/resume cycle
it might happen that the queues have not been setup again, causing a
crash during the attempt to stop the queues another time.
Fix that by checking the queues are existing before trying to stop
them.
This is XSA-465 / CVE-2024-53240.
๐@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: fix crash when removing device
When removing a netfront device directly after a suspend/resume cycle
it might happen that the queues have not been setup again, causing a
crash during the attempt to stop the queues another time.
Fix that by checking the queues are existing before trying to stop
them.
This is XSA-465 / CVE-2024-53240.
๐@cveNotify
๐จ CVE-2024-53241
In the Linux kernel, the following vulnerability has been resolved:
x86/xen: don't do PV iret hypercall through hypercall page
Instead of jumping to the Xen hypercall page for doing the iret
hypercall, directly code the required sequence in xen-asm.S.
This is done in preparation of no longer using hypercall page at all,
as it has shown to cause problems with speculation mitigations.
This is part of XSA-466 / CVE-2024-53241.
๐@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
x86/xen: don't do PV iret hypercall through hypercall page
Instead of jumping to the Xen hypercall page for doing the iret
hypercall, directly code the required sequence in xen-asm.S.
This is done in preparation of no longer using hypercall page at all,
as it has shown to cause problems with speculation mitigations.
This is part of XSA-466 / CVE-2024-53241.
๐@cveNotify
๐จ 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 ...