Threat and Vulnerability Intelligence Database
Example Searches:
CVE
Threat Actors
Countries
Vendors
Severity
Known Exploited
CVE-2024-53916 |
Description: In OpenStack Neutron before 25.0.1, neutron/extensions/tagging.py can use an incorrect ID during policy enforcement. It does not apply the proper policy check for changing network tags. An unprivileged tenant is able to change (add and clear) tags on network objects that do not belong to the tenant, and this action is not subjected to the proper policy authorization check. This affects 23 before 23.2.1, 24 before 24.0.2, and 25 before 25.0.1.
CVSS: LOW (0.0) EPSS Score: 0.05%
December 5th, 2024 (5 months ago)
|
|
CVE-2024-53900 |
Description: Mongoose before 8.8.3 can improperly use $where in match, leading to search injection.
CVSS: LOW (0.0) EPSS Score: 0.05%
December 5th, 2024 (5 months ago)
|
|
CVE-2024-53614 |
Description: A hardcoded decryption key in Thinkware Cloud APK v4.3.46 allows attackers to access sensitive data and execute arbitrary commands with elevated privileges.
CVSS: LOW (0.0) EPSS Score: 0.04%
December 5th, 2024 (5 months ago)
|
|
CVE-2024-53605 |
Description: Incorrect access control in the component content://com.handcent.messaging.provider.MessageProvider/ of Handcent NextSMS v10.9.9.7 allows attackers to access sensitive data.
CVSS: LOW (0.0) EPSS Score: 0.04%
December 5th, 2024 (5 months ago)
|
|
CVE-2024-53432 |
Description: While parsing certain malformed PLY files, PCL version 1.14.1 crashes due to an uncaught std::out_of_range exception in PCLPointCloud2::at. This issue could potentially be exploited to cause a denial-of-service (DoS) attack when processing untrusted PLY files.
CVSS: LOW (0.0) EPSS Score: 0.04%
December 5th, 2024 (5 months ago)
|
|
CVE-2024-53140 |
Description: In the Linux kernel, the following vulnerability has been resolved:
netlink: terminate outstanding dump on socket close
Netlink supports iterative dumping of data. It provides the families
the following ops:
- start - (optional) kicks off the dumping process
- dump - actual dump helper, keeps getting called until it returns 0
- done - (optional) pairs with .start, can be used for cleanup
The whole process is asynchronous and the repeated calls to .dump
don't actually happen in a tight loop, but rather are triggered
in response to recvmsg() on the socket.
This gives the user full control over the dump, but also means that
the user can close the socket without getting to the end of the dump.
To make sure .start is always paired with .done we check if there
is an ongoing dump before freeing the socket, and if so call .done.
The complication is that sockets can get freed from BH and .done
is allowed to sleep. So we use a workqueue to defer the call, when
needed.
Unfortunately this does not work correctly. What we defer is not
the cleanup but rather releasing a reference on the socket.
We have no guarantee that we own the last reference, if someone
else holds the socket they may release it in BH and we're back
to square one.
The whole dance, however, appears to be unnecessary. Only the user
can interact with dumps, so we can clean up when socket is closed.
And close always happens in process context. Some async code may
still access the socket after close, queue noti...
CVSS: LOW (0.0) EPSS Score: 0.04%
December 5th, 2024 (5 months ago)
|
|
CVE-2024-53139 |
Description: In the Linux kernel, the following vulnerability has been resolved:
sctp: fix possible UAF in sctp_v6_available()
A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints
that sctp_v6_available() is calling dev_get_by_index_rcu()
and ipv6_chk_addr() without holding rcu.
[1]
=============================
WARNING: suspicious RCU usage
6.12.0-rc5-virtme #1216 Tainted: G W
-----------------------------
net/core/dev.c:876 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by sctp_hello/31495:
#0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp
stack backtrace:
CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216
Tainted: [W]=WARN
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
dump_stack_lvl (lib/dump_stack.c:123)
lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)
dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7))
sctp_v6_available (net/sctp/ipv6.c:701) sctp
sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp
sctp_bind (net/sctp/socket.c:320) sctp
inet6_bind_sk (net/ipv6/af_inet6.c:465)
? security_socket_bind (security/security.c:4581 (discriminator 1))
__sys_bind (net/socket.c:1848 net/socket.c:1869)
? do_user_addr_fault (./include/linux/rcupdate.h:347 ./...
CVSS: LOW (0.0) EPSS Score: 0.04%
December 5th, 2024 (5 months ago)
|
|
CVE-2024-53138 |
Description: In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: kTLS, Fix incorrect page refcounting
The kTLS tx handling code is using a mix of get_page() and
page_ref_inc() APIs to increment the page reference. But on the release
path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.
This is an issue when using pages from large folios: the get_page()
references are stored on the folio page while the page_ref_inc()
references are stored directly in the given page. On release the folio
page will be dereferenced too many times.
This was found while doing kTLS testing with sendfile() + ZC when the
served file was read from NFS on a kernel with NFS large folios support
(commit 49b29a573da8 ("nfs: add support for large folios")).
CVSS: LOW (0.0) EPSS Score: 0.04%
December 5th, 2024 (5 months ago)
|
|
CVE-2024-53137 |
Description: In the Linux kernel, the following vulnerability has been resolved:
ARM: fix cacheflush with PAN
It seems that the cacheflush syscall got broken when PAN for LPAE was
implemented. User access was not enabled around the cache maintenance
instructions, causing them to fault.
CVSS: LOW (0.0) EPSS Score: 0.04%
December 5th, 2024 (5 months ago)
|
|
CVE-2024-53136 |
Description: In the Linux kernel, the following vulnerability has been resolved:
mm: revert "mm: shmem: fix data-race in shmem_getattr()"
Revert d949d1d14fa2 ("mm: shmem: fix data-race in shmem_getattr()") as
suggested by Chuck [1]. It is causing deadlocks when accessing tmpfs over
NFS.
As Hugh commented, "added just to silence a syzbot sanitizer splat: added
where there has never been any practical problem".
CVSS: LOW (0.0) EPSS Score: 0.04%
December 5th, 2024 (5 months ago)
|