In the Linux kernel, the following vulnerability has been resolved:
futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy()
During futex_key_to_node_opt() execution, vma->vm_policy is read under
speculative mmap lock and RCU. Concurrently, mbind() may call
vma_replace_policy() which frees the old mempolicy immediately via
kmem_cache_free().
This creates a race where __futex_key_to_node() dereferences a freed
mempolicy pointer, causing a use-after-free read of mpol->mode.
[ 151.412631] BUG: KASAN: slab-use-after-free in __futex_key_to_node (kernel/futex/core.c:349)
[ 151.414046] Read of size 2 at addr ffff888001c49634 by task e/87
[ 151.415969] Call Trace:
[ 151.416732] __asan_load2 (mm/kasan/generic.c:271)
[ 151.416777] __futex_key_to_node (kernel/futex/core.c:349)
[ 151.416822] get_futex_key (kernel/futex/core.c:374 kernel/futex/core.c:386 kernel/futex/core.c:593)
Fix by adding rcu to __mpol_put().
In the Linux kernel, the following vulnerability has been resolved:
mm/mseal: update VMA end correctly on merge
Previously we stored the end of the current VMA in curr_end, and then upon
iterating to the next VMA updated curr_start to curr_end to advance to the
next VMA.
However, this doesn't take into account the fact that a VMA might be
updated due to a merge by vma_modify_flags(), which can result in curr_end
being stale and thus, upon setting curr_start to curr_end, ending up with
an incorrect curr_start on the next iteration.
Resolve the issue by setting curr_end to vma->vm_end unconditionally to
ensure this value remains updated should this occur.
While we're here, eliminate this entire class of bug by simply setting
const curr_[start/end] to be clamped to the input range and VMAs, which
also happens to simplify the logic.
An unauthenticated remote attacker can exploit an unauthenticated blind SQL Injection vulnerability in the mb24api endpoint due to improper neutralization of special elements in a SQL SELECT command. This can result in a total loss of confidentiality.
An unauthenticated remote attacker can access a configuration file containing database credentials. This can result in a some loss of confidentiality, but there is no endpoint exposed to use these credentials.
An unauthenticated remote attacker can exploit an unauthenticated SQL Injection vulnerability in the getinfo endpoint due to improper neutralization of special elements in a SQL SELECT command. This can result in a total loss of confidentiality.
An unauthenticated remote attacker can exploit an unauthenticated SQL Injection vulnerability in the setinfo endpoint due to improper neutralization of special elements in a SQL UPDATE command. This can result in a total loss of integrity and availability.
Due to the improper neutralisation of special elements used in an OS command, a remote attacker can exploit an RCE vulnerability in the generateSrpArray function, resulting in full system compromise.
This vulnerability can only be attacked if the attacker has some other way to write arbitrary data to the user table.
SEPPmail Secure Email Gateway before version 15.0.3 does not properly authenticate the inner message of S/MIME-encrypted MIME entities, allowing an attacker to control trusted headers.
SEPPmail Secure Email Gateway before version 15.0.3 allows an attacker to bypass subject sanitization and forge security tags using Unicode lookalike characters.