| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| NVIDIA Linux GPU Display Driver contains a vulnerability in the NGX updater where an outdated embedded cryptographic library is susceptible to type confusion. A successful exploit of this vulnerability might lead to code execution, denial of service, information disclosure, or data tampering. |
| NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer where a user could cause type confusion. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. |
| Inappropriate implementation in NFC in Google Chrome prior to 154.0.8037.57 allowed a remote attacker to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium) |
| NVIDIA GPU Display Driver for Windows contains a vulnerability in the kernel module where an attacker could cause type confusion. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. |
| NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer where a user could cause a type confusion via a handle recycle race. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. |
| A flaw was found in libsoup. When handling an incoming WebSocket Pong frame, SoupWebsocketConnection emitted the ::pong signal with a GByteArray pointer even though the signal is declared to pass a GBytes. Applications connecting a handler that follows the documented GBytes API can trigger heap corruption or a crash upon receiving a crafted Pong. |
| Type confusion in V8 in Google Chrome prior to 154.0.8037.57 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| DBI versions before 1.654 for Perl incorrectly treat numeric values as strings in FetchHashKeyName.
fetchrow_hashref uses the string pointer of the FetchHashKeyName attribute as the key name without stringifying it first. When FetchHashKeyName has been set to an integer (IV) or floating-point (NV) value, that pointer is invalid, so reading the key name triggers a segmentation fault.
This can be triggered with the following code:
my $dbh = DBI->connect( "dbi:ExampleP:", "", "",
{ RaiseError => 0, PrintError => 0 } );
$dbh->{FetchHashKeyName} = 42;
my $sth = $dbh->prepare("select mode, size, name from .");
$sth->execute;
$sth->fetchrow_hashref; |
| DBI versions before 1.654 for Perl incorrectly treat numeric values as strings in sql_type_cast_svpv.
When casting to SQL_NUMERIC, sql_type_cast_svpv passes the string pointer and length of the SV to grok_number without stringifying it first. An integer (IV) or floating-point (NV) value has no valid string pointer, so grok_number reads from an invalid address, triggering a segmentation fault.
This is reachable in Perl using the sql_type_cast function:
my $num = 42;
DBI::sql_type_cast( $num, DBI::SQL_NUMERIC, 0 ); |
| XS::Parse::Infix versions from 0.40 through 0.49 for Perl treat a number as an array reference.
The wrapper function XS::Parse::Infix generates for a list-associative infix operator checks whether arguments are array references, but it tests using SvRV() rather than SvROK(). SvRV() reads a union slot that only holds a referent once SvROK(sv) is true, so the guard never validates that it is a reference. For an IV or NV that slot holds the number itself, SvRV() returns the caller's value and SvTYPE() dereferences it at offset 12. This will generally result in a segmentation fault.
An application that hands the wrapper a list built from decoded input (for example, from JSON) lets whoever supplies a number in that list choose the address that the interpreter dereferences.
An ordinary string's byte 12 is rarely SVt_PVAV so the guard croaks by luck, but an attacker-crafted string carrying 0x0b there passes, and the buffer is then used as an AV head, with AvARRAY taken from bytes 16-23 and its entries pushed onto the Perl stack as live SVs.
A simple proof-of-concept uses the zip operator:
use Syntax::Operator::Zip 'zip';
my @args = ([1], 2);
zip(@args); |
| Type confusion in Bindings in Google Chrome prior to 154.0.8037.57 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Type confusion in V8 in Google Chrome prior to 154.0.8037.92 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Type confusion in V8 in Google Chrome prior to 154.0.8037.92 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Type confusion in V8 in Google Chrome prior to 154.0.8037.92 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Type confusion in V8 in Google Chrome prior to 154.0.8037.92 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Mark NULL kptr stores precise
check_map_kptr_access() permits a scalar store into an untrusted kptr
field only when the register is known to contain zero. Unlike other
verifier checks whose outcome depends on a scalar value, it does not mark
that register precise.
A state checkpoint reached with an imprecise zero can therefore prune a
second path that reaches the store with an arbitrary nonzero scalar. The
program can write attacker-controlled bits into the kptr field and load
them back as a PTR_TO_BTF_ID.
Call mark_chain_precision() before accepting a known-zero register. This
forces state equivalence to compare its scalar range and makes the verifier
visit and reject a path carrying a nonzero value. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: don't rewrite bpf_fastcall patterns entered by a jump
mark_fastcall_pattern_for_call() must ensure that matched
"spill; call; fill" instruction series is not interrupted by a jump.
Otherwise the rewrite applied by bpf_remove_fastcall_spills_fills()
is not sound.
Record the instructions targeted by jumps in
insn_aux_data[*].jump_target when the CFG is built and use this flag
to stop growing a pattern at such an instruction. Jumps to the first
spill are fine.
Note that existing insn_aux_data[*].jmp_point field can't be reused,
as it marks subprogram return instructions. |
| Out-of-bounds read in Microsoft Standard XPS allows an authorized attacker to disclose information locally. |
| A flaw was found in Moodle. When enrolling a user into a course while assigning them to a group, the application does not verify whether the selected group actually belongs to that course. An authenticated user with teacher privileges could exploit this flaw to add users to groups within courses they do not have authorization to access. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: don't downgrade half-dead scalar zero spills to STACK_ZERO
states.c:__clean_func_state() can downgrade scalar zero spill to
STACK_ZERO in the following case:
*(u64 *)(r10 - 8) = 0;
... checkpoint ...
r1 = *(u32 *)(r10 - 4);
... no reads from r10-8 ...
Here 4 bytes at r10-8 are dead and verifier changes scalar spill to a
combination: 0000pppp (p stands for poison). Such a change breaks
precision propagation chains. All places that produce STACK_ZERO
should call bpf_mark_chain_precision() for the zero source.
This patch fixes the bug in a simplest way possible:
avoids converting stack spills of zero to STACK_ZERO.
Two smarter approaches are possible:
- do bpf_mark_chain_precision() from __clean_func_state()
- check slot liveness information in check_stack_write_fixed_off()
I investigated both and the changes required are a bit tricky,
hence go with a simple fix for the time being. |