| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: mops: Do not dereference src reg for a set operation
The source register is not used for SET* and reading it can result in
a UBSAN out-of-bounds array access error, specifically when the MOPS
exception is taken from a SET* sequence with XZR (reg 31) as the
source. Architecturally this is the only case where a src/dst/size
field in the ESR can be reported as 31.
Prior to 2de451a329cf662b the code in do_el0_mops() was benign as the
use of pt_regs_read_reg() prevented the out-of-bounds access. |
| A vulnerability has been found in 70mai X200 up to 20251010. Affected by this vulnerability is an unknown functionality of the component HTTP Web Server. The manipulation leads to use of default credentials. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| Dell Alienware Command Center 6.x (AWCC), versions prior to 6.10.15.0, contain a Process Control vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Information Disclosure. |
| Inappropriate implementation in Dawn in Google Chrome on Mac prior to 130.0.6723.92 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High) |
| Out of bounds read in V8 in Google Chrome prior to 133.0.6943.141 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium) |
| Inappropriate implementation in Compositing in Google Chrome prior to 140.0.7339.80 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low) |
| A vulnerability in the CLI of Cisco IOS XE Software could allow an authenticated, local attacker with administrative privileges to execute arbitrary commands as root on the underlying operating system of an affected device.
This vulnerability is due to insufficient validation of user arguments that are passed to specific CLI commands. An attacker could exploit this vulnerability by logging in to the device CLI with valid administrative (level 15) credentials and using crafted commands at the CLI prompt. A successful exploit could allow the attacker to execute arbitrary commands as root. |
| In the Linux kernel, the following vulnerability has been resolved:
spi-rockchip: Fix register out of bounds access
Do not write native chip select stuff for GPIO chip selects.
GPIOs can be numbered much higher than native CS.
Also, it makes no sense. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: bcm: rpi: Prevent out-of-bounds access
The while loop in raspberrypi_discover_clocks() relies on the assumption
that the id of the last clock element is zero. Because this data comes
from the Videocore firmware and it doesn't guarantuee such a behavior
this could lead to out-of-bounds access. So fix this by providing
a sentinel element. |
| In the Linux kernel, the following vulnerability has been resolved:
hwmon: (gpio-fan) Fix array out of bounds access
The driver does not check if the cooling state passed to
gpio_fan_set_cur_state() exceeds the maximum cooling state as
stored in fan_data->num_speeds. Since the cooling state is later
used as an array index in set_fan_speed(), an array out of bounds
access can occur.
This can be exploited by setting the state of the thermal cooling device
to arbitrary values, causing for example a kernel oops when unavailable
memory is accessed this way.
Example kernel oops:
[ 807.987276] Unable to handle kernel paging request at virtual address ffffff80d0588064
[ 807.987369] Mem abort info:
[ 807.987398] ESR = 0x96000005
[ 807.987428] EC = 0x25: DABT (current EL), IL = 32 bits
[ 807.987477] SET = 0, FnV = 0
[ 807.987507] EA = 0, S1PTW = 0
[ 807.987536] FSC = 0x05: level 1 translation fault
[ 807.987570] Data abort info:
[ 807.987763] ISV = 0, ISS = 0x00000005
[ 807.987801] CM = 0, WnR = 0
[ 807.987832] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000001165000
[ 807.987872] [ffffff80d0588064] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[ 807.987961] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 807.987992] Modules linked in: cmac algif_hash aes_arm64 algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc snd_soc_hdmi_codec brcmfmac vc4 brcmutil cec drm_kms_helper snd_soc_core cfg80211 snd_compress bcm2835_codec(C) snd_pcm_dmaengine syscopyarea bcm2835_isp(C) bcm2835_v4l2(C) sysfillrect v4l2_mem2mem bcm2835_mmal_vchiq(C) raspberrypi_hwmon sysimgblt videobuf2_dma_contig videobuf2_vmalloc fb_sys_fops videobuf2_memops rfkill videobuf2_v4l2 videobuf2_common i2c_bcm2835 snd_bcm2835(C) videodev snd_pcm snd_timer snd mc vc_sm_cma(C) gpio_fan uio_pdrv_genirq uio drm fuse drm_panel_orientation_quirks backlight ip_tables x_tables ipv6
[ 807.988508] CPU: 0 PID: 1321 Comm: bash Tainted: G C 5.15.56-v8+ #1575
[ 807.988548] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
[ 807.988574] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 807.988608] pc : set_fan_speed.part.5+0x34/0x80 [gpio_fan]
[ 807.988654] lr : gpio_fan_set_cur_state+0x34/0x50 [gpio_fan]
[ 807.988691] sp : ffffffc008cf3bd0
[ 807.988710] x29: ffffffc008cf3bd0 x28: ffffff80019edac0 x27: 0000000000000000
[ 807.988762] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800747c920
[ 807.988787] x23: 000000000000000a x22: ffffff800369f000 x21: 000000001999997c
[ 807.988854] x20: ffffff800369f2e8 x19: ffffff8002ae8080 x18: 0000000000000000
[ 807.988877] x17: 0000000000000000 x16: 0000000000000000 x15: 000000559e271b70
[ 807.988938] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[ 807.988960] x11: 0000000000000000 x10: ffffffc008cf3c20 x9 : ffffffcfb60c741c
[ 807.989018] x8 : 000000000000000a x7 : 00000000ffffffc9 x6 : 0000000000000009
[ 807.989040] x5 : 000000000000002a x4 : 0000000000000000 x3 : ffffff800369f2e8
[ 807.989062] x2 : 000000000000e780 x1 : 0000000000000001 x0 : ffffff80d0588060
[ 807.989084] Call trace:
[ 807.989091] set_fan_speed.part.5+0x34/0x80 [gpio_fan]
[ 807.989113] gpio_fan_set_cur_state+0x34/0x50 [gpio_fan]
[ 807.989199] cur_state_store+0x84/0xd0
[ 807.989221] dev_attr_store+0x20/0x38
[ 807.989262] sysfs_kf_write+0x4c/0x60
[ 807.989282] kernfs_fop_write_iter+0x130/0x1c0
[ 807.989298] new_sync_write+0x10c/0x190
[ 807.989315] vfs_write+0x254/0x378
[ 807.989362] ksys_write+0x70/0xf8
[ 807.989379] __arm64_sys_write+0x24/0x30
[ 807.989424] invoke_syscall+0x4c/0x110
[ 807.989442] el0_svc_common.constprop.3+0xfc/0x120
[ 807.989458] do_el0_svc+0x2c/0x90
[ 807.989473] el0_svc+0x24/0x60
[ 807.989544] el0t_64_sync_handler+0x90/0xb8
[ 807.989558] el0t_64_sync+0x1a0/0x1a4
[ 807.989579] Code: b9403801 f9402800 7100003f 8b35cc00 (b9400416)
[ 807.989627] ---[ end t
---truncated--- |
| CodeChecker is an analyzer tooling, defect database and viewer extension for the Clang Static Analyzer and Clang Tidy.
CodeChecker versions up to 6.26.1 contain a buffer overflow vulnerability in the internal ldlogger library, which is executed by the CodeChecker log command.
This issue affects CodeChecker: through 6.26.1. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Don't use tnum_range on array range checking for poke descriptors
Hsin-Wei reported a KASAN splat triggered by their BPF runtime fuzzer which
is based on a customized syzkaller:
BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x1257/0x13f0
Read of size 8 at addr ffff888004e90b58 by task syz-executor.0/1489
CPU: 1 PID: 1489 Comm: syz-executor.0 Not tainted 5.19.0 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x9c/0xc9
print_address_description.constprop.0+0x1f/0x1f0
? bpf_int_jit_compile+0x1257/0x13f0
kasan_report.cold+0xeb/0x197
? kvmalloc_node+0x170/0x200
? bpf_int_jit_compile+0x1257/0x13f0
bpf_int_jit_compile+0x1257/0x13f0
? arch_prepare_bpf_dispatcher+0xd0/0xd0
? rcu_read_lock_sched_held+0x43/0x70
bpf_prog_select_runtime+0x3e8/0x640
? bpf_obj_name_cpy+0x149/0x1b0
bpf_prog_load+0x102f/0x2220
? __bpf_prog_put.constprop.0+0x220/0x220
? find_held_lock+0x2c/0x110
? __might_fault+0xd6/0x180
? lock_downgrade+0x6e0/0x6e0
? lock_is_held_type+0xa6/0x120
? __might_fault+0x147/0x180
__sys_bpf+0x137b/0x6070
? bpf_perf_link_attach+0x530/0x530
? new_sync_read+0x600/0x600
? __fget_files+0x255/0x450
? lock_downgrade+0x6e0/0x6e0
? fput+0x30/0x1a0
? ksys_write+0x1a8/0x260
__x64_sys_bpf+0x7a/0xc0
? syscall_enter_from_user_mode+0x21/0x70
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f917c4e2c2d
The problem here is that a range of tnum_range(0, map->max_entries - 1) has
limited ability to represent the concrete tight range with the tnum as the
set of resulting states from value + mask can result in a superset of the
actual intended range, and as such a tnum_in(range, reg->var_off) check may
yield true when it shouldn't, for example tnum_range(0, 2) would result in
00XX -> v = 0000, m = 0011 such that the intended set of {0, 1, 2} is here
represented by a less precise superset of {0, 1, 2, 3}. As the register is
known const scalar, really just use the concrete reg->var_off.value for the
upper index check. |
| Unauthenticated attackers can send configuration settings to device and possible perform physical actions remotely (e.g., on/off). |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO
Precision markers need to be propagated whenever we have an ARG_CONST_*
style argument, as the verifier cannot consider imprecise scalars to be
equivalent for the purposes of states_equal check when such arguments
refine the return value (in this case, set mem_size for PTR_TO_MEM). The
resultant mem_size for the R0 is derived from the constant value, and if
the verifier incorrectly prunes states considering them equivalent where
such arguments exist (by seeing that both registers have reg->precise as
false in regsafe), we can end up with invalid programs passing the
verifier which can do access beyond what should have been the correct
mem_size in that explored state.
To show a concrete example of the problem:
0000000000000000 <prog>:
0: r2 = *(u32 *)(r1 + 80)
1: r1 = *(u32 *)(r1 + 76)
2: r3 = r1
3: r3 += 4
4: if r3 > r2 goto +18 <LBB5_5>
5: w2 = 0
6: *(u32 *)(r1 + 0) = r2
7: r1 = *(u32 *)(r1 + 0)
8: r2 = 1
9: if w1 == 0 goto +1 <LBB5_3>
10: r2 = -1
0000000000000058 <LBB5_3>:
11: r1 = 0 ll
13: r3 = 0
14: call bpf_ringbuf_reserve
15: if r0 == 0 goto +7 <LBB5_5>
16: r1 = r0
17: r1 += 16777215
18: w2 = 0
19: *(u8 *)(r1 + 0) = r2
20: r1 = r0
21: r2 = 0
22: call bpf_ringbuf_submit
00000000000000b8 <LBB5_5>:
23: w0 = 0
24: exit
For the first case, the single line execution's exploration will prune
the search at insn 14 for the branch insn 9's second leg as it will be
verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will
always be 0 so at runtime we don't get error for being greater than
UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just
sees reg->precise as false for both r2 registers in both states, hence
considers them equal for purposes of states_equal.
If we propagated precise markers using the backtracking support, we
would use the precise marking to then ensure that old r2 (UINT_MAX) was
within the new r2 (1) and this would never be true, so the verification
would rightfully fail.
The end result is that the out of bounds access at instruction 19 would
be permitted without this fix.
Note that reg->precise is always set to true when user does not have
CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static
or global functions)), hence this is only a problem when precision marks
need to be explicitly propagated (i.e. privileged users with CAP_BPF).
A simplified test case has been included in the next patch to prevent
future regressions. |
| NULL pointer dereference vulnerability exists in GNU libmicrohttpd v1.0.2 and earlier. The vulnerability was fixed in commit ff13abc on the master branch of the libmicrohttpd Git repository, after the v1.0.2 tag. A specially crafted packet sent by an attacker could cause a denial-of-service (DoS) condition. |
| The VAPIX API port.cgi did not have sufficient input validation, which may result in process crashes and impact usability. This vulnerability can only be exploited after authenticating with a viewer- operator- or administrator-privileged service account. |
| In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: Leak pages if set_memory_encrypted() fails
In CoCo VMs it is possible for the untrusted host to cause
set_memory_encrypted() or set_memory_decrypted() to fail such that an
error is returned and the resulting memory is shared. Callers need to
take care to handle these errors to avoid returning decrypted (shared)
memory to the page allocator, which could lead to functional or security
issues.
VMBus code could free decrypted pages if set_memory_encrypted()/decrypted()
fails. Leak the pages if this happens. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: fix out-of-bounds access during multi-link element defragmentation
Currently during the multi-link element defragmentation process, the
multi-link element length added to the total IEs length when calculating
the length of remaining IEs after the multi-link element in
cfg80211_defrag_mle(). This could lead to out-of-bounds access if the
multi-link element or its corresponding fragment elements are the last
elements in the IEs buffer.
To address this issue, correctly calculate the remaining IEs length by
deducting the multi-link element end offset from total IEs end offset. |
| In the Linux kernel, the following vulnerability has been resolved:
riscv: module: Fix out-of-bounds relocation access
The current code allows rel[j] to access one element past the end of the
relocation section. Simplify to num_relocations which is equivalent to
the existing size expression. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP()
Herbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa
implementation's ->key_size() callback returns an unusually large value.
Herbert instead suggests (for a division by 8):
X / 8 + !!(X & 7)
Based on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and
use it in lieu of DIV_ROUND_UP() for ->key_size() return values.
Additionally, use the macro in ecc_digits_from_bytes(), whose "nbytes"
parameter is a ->key_size() return value in some instances, or a
user-specified ASN.1 length in the case of ecdsa_get_signature_rs(). |
