| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Improper Isolation or Compartmentalization in the stream cache mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege via local access. |
| Improper buffer restrictions for some Intel(R) Xeon(R) Processor firmware with SGX enabled may allow a privileged user to potentially enable escalation of privilege via local access. |
| A local privilege escalation vulnerability exists in the safe_asterisk script included with the Asterisk toolkit package. When Asterisk is started via this script (common in SysV init or FreePBX environments), it sources all .sh files located in /etc/asterisk/startup.d/ as root, without validating ownership or permissions.
Non-root users with legitimate write access to /etc/asterisk can exploit this behaviour by placing malicious scripts in the startup.d directory, which will then execute with root privileges upon service restart. |
| HYDRA X, MIP 2 and FEDRA 2 of MPDV Mikrolab GmbH suffer from an unauthenticated local file disclosure vulnerability in all releases until Maintenance Pack 36 with Servicepack 8 (week 36/2025), which allows an attacker to read arbitrary files from the Windows operating system. The "Filename" parameter of the public $SCHEMAS$ ressource is vulnerable and can be exploited easily. |
| Memory safety bugs present in Firefox ESR 140.3, Thunderbird ESR 140.3, Firefox 143 and Thunderbird 143. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 144, Firefox ESR < 140.4, Thunderbird < 144, and Thunderbird < 140.4. |
| Memory safety bugs present in Firefox ESR 115.28, Firefox ESR 140.3, Thunderbird ESR 140.3, Firefox 143 and Thunderbird 143. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 144, Firefox ESR < 115.29, Firefox ESR < 140.4, Thunderbird < 144, and Thunderbird < 140.4. |
| A malicious page could have used the type attribute of an OBJECT tag to override the default browser behavior when encountering a web resource served without a content-type. This could have contributed to an XSS on a site that unsafely serves files without a content-type header. This vulnerability affects Firefox < 144, Firefox ESR < 140.4, Thunderbird < 144, and Thunderbird < 140.4. |
| There was a way to change the value of JavaScript Object properties that were supposed to be non-writeable. This vulnerability affects Firefox < 144, Firefox ESR < 115.29, Firefox ESR < 140.4, Thunderbird < 144, and Thunderbird < 140.4. |
| A compromised web process using malicious IPC messages could have caused the privileged browser process to reveal blocks of its memory to the compromised process. This vulnerability affects Firefox < 144, Firefox ESR < 115.29, Firefox ESR < 140.4, Thunderbird < 144, and Thunderbird < 140.4. |
| A compromised web process was able to trigger out of bounds reads and writes in a more privileged process using manipulated WebGL textures. This vulnerability affects Firefox < 144, Firefox ESR < 115.29, Firefox ESR < 140.4, Thunderbird < 144, and Thunderbird < 140.4. |
| Use-after-free in MediaTrackGraphImpl::GetInstance() This vulnerability affects Firefox < 144, Firefox ESR < 140.4, Thunderbird < 144, and Thunderbird < 140.4. |
| All WorkExaminer Professional traffic between monitoring client, console and server is transmitted as plain text. This allows an attacker with access to the network to read the transmitted sensitive data. An attacker can also freely modify the data on the wire. The monitoring clients transmit their data to the server using the unencrypted FTP. Clients connect to the FTP server on port 12304 and transmit the data unencrypted. In addition, all traffic between the console client and the server at port 12306 is unencrypted. |
| An unauthenticated attacker with access to TCP port 12306 of the WorkExaminer server can exploit missing server-side authentication checks to bypass the login prompt in the WorkExaminer Professional console to gain administrative access to the WorkExaminer server and therefore all sensitive monitoring data. This includes monitored screenshots and keystrokes of all users.
The WorkExaminer Professional console is used for administrative access to the server. Before access to the console is granted administrators must login. Internally, a custom protocol is used to call a respective stored procedure on the MSSQL database. The return value of the call is not validated on the server-side. Instead it is only validated client-side which allows to bypass authentication. |
| The WorkExaminer Professional server installation comes with an FTP server that is used to receive the client logs on TCP port 12304. An attacker with network access to this port can use weak hardcoded credentials to login to the FTP server and modify or read data, log files and gain remote code execution as NT Authority\SYSTEM on the server by exchanging accessible service binaries in the WorkExaminer installation directory (e.g. "C:\Program File (x86)\Work Examiner Professional Server"). |
| When batch jobs are executed by pgAgent, a script is created in a temporary directory and then executed. In versions of pgAgent prior to 4.2.3, an insufficiently seeded random number generator is used when generating the directory name, leading to the possibility for a local attacker to pre-create the directory and thus prevent pgAgent from executing jobs, disrupting scheduled tasks. |
| In the Linux kernel, the following vulnerability has been resolved:
tls: separate no-async decryption request handling from async
If we're not doing async, the handling is much simpler. There's no
reference counting, we just need to wait for the completion to wake us
up and return its result.
We should preferably also use a separate crypto_wait. I'm not seeing a
UAF as I did in the past, I think aec7961916f3 ("tls: fix race between
async notify and socket close") took care of it.
This will make the next fix easier. |
| In the Linux kernel, the following vulnerability has been resolved:
fs: relax assertions on failure to encode file handles
Encoding file handles is usually performed by a filesystem >encode_fh()
method that may fail for various reasons.
The legacy users of exportfs_encode_fh(), namely, nfsd and
name_to_handle_at(2) syscall are ready to cope with the possibility
of failure to encode a file handle.
There are a few other users of exportfs_encode_{fh,fid}() that
currently have a WARN_ON() assertion when ->encode_fh() fails.
Relax those assertions because they are wrong.
The second linked bug report states commit 16aac5ad1fa9 ("ovl: support
encoding non-decodable file handles") in v6.6 as the regressing commit,
but this is not accurate.
The aforementioned commit only increases the chances of the assertion
and allows triggering the assertion with the reproducer using overlayfs,
inotify and drop_caches.
Triggering this assertion was always possible with other filesystems and
other reasons of ->encode_fh() failures and more particularly, it was
also possible with the exact same reproducer using overlayfs that is
mounted with options index=on,nfs_export=on also on kernels < v6.6.
Therefore, I am not listing the aforementioned commit as a Fixes commit.
Backport hint: this patch will have a trivial conflict applying to
v6.6.y, and other trivial conflicts applying to stable kernels < v6.6. |
| In the Linux kernel, the following vulnerability has been resolved:
mm: hugetlb: independent PMD page table shared count
The folio refcount may be increased unexpectly through try_get_folio() by
caller such as split_huge_pages. In huge_pmd_unshare(), we use refcount
to check whether a pmd page table is shared. The check is incorrect if
the refcount is increased by the above caller, and this can cause the page
table leaked:
BUG: Bad page state in process sh pfn:109324
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324
flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff)
page_type: f2(table)
raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000
raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000
page dumped because: nonzero mapcount
...
CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7
Tainted: [B]=BAD_PAGE
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
Call trace:
show_stack+0x20/0x38 (C)
dump_stack_lvl+0x80/0xf8
dump_stack+0x18/0x28
bad_page+0x8c/0x130
free_page_is_bad_report+0xa4/0xb0
free_unref_page+0x3cc/0x620
__folio_put+0xf4/0x158
split_huge_pages_all+0x1e0/0x3e8
split_huge_pages_write+0x25c/0x2d8
full_proxy_write+0x64/0xd8
vfs_write+0xcc/0x280
ksys_write+0x70/0x110
__arm64_sys_write+0x24/0x38
invoke_syscall+0x50/0x120
el0_svc_common.constprop.0+0xc8/0xf0
do_el0_svc+0x24/0x38
el0_svc+0x34/0x128
el0t_64_sync_handler+0xc8/0xd0
el0t_64_sync+0x190/0x198
The issue may be triggered by damon, offline_page, page_idle, etc, which
will increase the refcount of page table.
1. The page table itself will be discarded after reporting the
"nonzero mapcount".
2. The HugeTLB page mapped by the page table miss freeing since we
treat the page table as shared and a shared page table will not be
unmapped.
Fix it by introducing independent PMD page table shared count. As
described by comment, pt_index/pt_mm/pt_frag_refcount are used for s390
gmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv
pmds, so we can reuse the field as pt_share_count. |
| In Raptor RDF Syntax Library through 2.0.16, there is an integer underflow when normalizing a URI with the turtle parser in raptor_uri_normalize_path(). |
| In Raptor RDF Syntax Library through 2.0.16, there is a heap-based buffer over-read when parsing triples with the nquads parser in raptor_ntriples_parse_term_internal(). |
