| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability has been found in Tenda AC23 up to 16.03.07.52. Affected by this vulnerability is the function sscanf of the file /goform/SetPptpServerCfg of the component HTTP POST Request Handler. Such manipulation of the argument startIp leads to buffer overflow. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. |
| NanoMQ 0.17.5 has a one-byte heap-based buffer over-read in the conn_handler function of mqtt_parser.c when it processes malformed messages. |
| An integer overflow in WhatsApp could result in remote code execution in an established video call. |
| A vulnerability has been identified in Teamcenter Visualization V14.2 (All versions < V14.2.0.14), Teamcenter Visualization V14.3 (All versions < V14.3.0.12), Teamcenter Visualization V2312 (All versions < V2312.0008), Tecnomatix Plant Simulation V2302 (All versions < V2302.0016), Tecnomatix Plant Simulation V2404 (All versions < V2404.0005). The affected applications contain a stack based overflow vulnerability while parsing specially crafted WRL files.
This could allow an attacker to execute code in the context of the current process. (ZDI-CAN-25000) |
| A vulnerability has been identified in Teamcenter Visualization V14.2 (All versions < V14.2.0.14), Teamcenter Visualization V14.3 (All versions < V14.3.0.12), Teamcenter Visualization V2312 (All versions < V2312.0008), Tecnomatix Plant Simulation V2302 (All versions < V2302.0016), Tecnomatix Plant Simulation V2404 (All versions < V2404.0005). The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted WRL files.
This could allow an attacker to execute code in the context of the current process. (ZDI-CAN-25206) |
| In the Linux kernel, the following vulnerability has been resolved:
nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells
If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic
*p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);
will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we
subtract one from that making a large number that is then shifted more than the
number of bits that fit into an unsigned long.
UBSAN reports this problem:
UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8
shift exponent 64 is too large for 64-bit type 'unsigned long'
CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
Workqueue: events_unbound deferred_probe_work_func
Call trace:
dump_backtrace+0x0/0x170
show_stack+0x24/0x30
dump_stack_lvl+0x64/0x7c
dump_stack+0x18/0x38
ubsan_epilogue+0x10/0x54
__ubsan_handle_shift_out_of_bounds+0x180/0x194
__nvmem_cell_read+0x1ec/0x21c
nvmem_cell_read+0x58/0x94
nvmem_cell_read_variable_common+0x4c/0xb0
nvmem_cell_read_variable_le_u32+0x40/0x100
a6xx_gpu_init+0x170/0x2f4
adreno_bind+0x174/0x284
component_bind_all+0xf0/0x264
msm_drm_bind+0x1d8/0x7a0
try_to_bring_up_master+0x164/0x1ac
__component_add+0xbc/0x13c
component_add+0x20/0x2c
dp_display_probe+0x340/0x384
platform_probe+0xc0/0x100
really_probe+0x110/0x304
__driver_probe_device+0xb8/0x120
driver_probe_device+0x4c/0xfc
__device_attach_driver+0xb0/0x128
bus_for_each_drv+0x90/0xdc
__device_attach+0xc8/0x174
device_initial_probe+0x20/0x2c
bus_probe_device+0x40/0xa4
deferred_probe_work_func+0x7c/0xb8
process_one_work+0x128/0x21c
process_scheduled_works+0x40/0x54
worker_thread+0x1ec/0x2a8
kthread+0x138/0x158
ret_from_fork+0x10/0x20
Fix it by making sure there are any bits to mask out. |
| In the Linux kernel, the following vulnerability has been resolved:
net/tls: Fix flipped sign in tls_err_abort() calls
sk->sk_err appears to expect a positive value, a convention that ktls
doesn't always follow and that leads to memory corruption in other code.
For instance,
[kworker]
tls_encrypt_done(..., err=<negative error from crypto request>)
tls_err_abort(.., err)
sk->sk_err = err;
[task]
splice_from_pipe_feed
...
tls_sw_do_sendpage
if (sk->sk_err) {
ret = -sk->sk_err; // ret is positive
splice_from_pipe_feed (continued)
ret = actor(...) // ret is still positive and interpreted as bytes
// written, resulting in underflow of buf->len and
// sd->len, leading to huge buf->offset and bogus
// addresses computed in later calls to actor()
Fix all tls_err_abort() callers to pass a negative error code
consistently and centralize the error-prone sign flip there, throwing in
a warning to catch future misuse and uninlining the function so it
really does only warn once. |
| An issue was discovered in MBed OS 6.16.0. When parsing hci reports, the hci parsing software dynamically determines the length of a list of reports by reading a byte from an input stream. It then fetches the length of the first report, uses it to calculate the beginning of the second report, etc. In doing this, it tracks the largest report so it can later allocate a buffer that fits every individual report (but only one at a time). It does not, however, validate that these addresses are all contained within the buffer passed to hciEvtProcessLeExtAdvReport. It is then possible, though unlikely, that the buffer designated to hold the reports is allocated in such a way that one of these out-of-bounds length fields is contained within the new buffer. When the (n-1)th report is copied, it overwrites the length field of the nth report. This now corrupted length field is then used for a memcpy into the new buffer, which may lead to a buffer overflow. |
| In the Linux kernel, the following vulnerability has been resolved:
comedi: vmk80xx: fix bulk-buffer overflow
The driver is using endpoint-sized buffers but must not assume that the
tx and rx buffers are of equal size or a malicious device could overflow
the slab-allocated receive buffer when doing bulk transfers. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest()
In commit 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in
C") kvm_start_guest() became idle_kvm_start_guest(). The old code
allocated a stack frame on the emergency stack, but didn't use the
frame to store anything, and also didn't store anything in its caller's
frame.
idle_kvm_start_guest() on the other hand is written more like a normal C
function, it creates a frame on entry, and also stores CR/LR into its
callers frame (per the ABI). The problem is that there is no caller
frame on the emergency stack.
The emergency stack for a given CPU is allocated with:
paca_ptrs[i]->emergency_sp = alloc_stack(limit, i) + THREAD_SIZE;
So emergency_sp actually points to the first address above the emergency
stack allocation for a given CPU, we must not store above it without
first decrementing it to create a frame. This is different to the
regular kernel stack, paca->kstack, which is initialised to point at an
initial frame that is ready to use.
idle_kvm_start_guest() stores the backchain, CR and LR all of which
write outside the allocation for the emergency stack. It then creates a
stack frame and saves the non-volatile registers. Unfortunately the
frame it creates is not large enough to fit the non-volatiles, and so
the saving of the non-volatile registers also writes outside the
emergency stack allocation.
The end result is that we corrupt whatever is at 0-24 bytes, and 112-248
bytes above the emergency stack allocation.
In practice this has gone unnoticed because the memory immediately above
the emergency stack happens to be used for other stack allocations,
either another CPUs mc_emergency_sp or an IRQ stack. See the order of
calls to irqstack_early_init() and emergency_stack_init().
The low addresses of another stack are the top of that stack, and so are
only used if that stack is under extreme pressue, which essentially
never happens in practice - and if it did there's a high likelyhood we'd
crash due to that stack overflowing.
Still, we shouldn't be corrupting someone else's stack, and it is purely
luck that we aren't corrupting something else.
To fix it we save CR/LR into the caller's frame using the existing r1 on
entry, we then create a SWITCH_FRAME_SIZE frame (which has space for
pt_regs) on the emergency stack with the backchain pointing to the
existing stack, and then finally we switch to the new frame on the
emergency stack. |
| A vulnerability was determined in axboe fio up to 3.41. This impacts the function __parse_jobs_ini of the file init.c. Executing manipulation can lead to use after free. The attack needs to be launched locally. The exploit has been publicly disclosed and may be utilized. |
| The Advanced Views – Display Posts, Custom Fields, and More plugin for WordPress is vulnerable to Server-Side Template Injection in all versions up to, and including, 3.7.19. This is due to insufficient input sanitization and lack of access control when processing custom Twig templates in the Model panel. This makes it possible for authenticated attackers, with author-level access or higher, to execute arbitrary PHP code and commands on the server. |
| A CORS misconfiguration in Nginx Proxy Manager v2.12.3 allows unauthorized domains to access sensitive data, particularly JWT tokens, due to improper validation of the Origin header. This misconfiguration enables attackers to intercept tokens using a simple browser script and exfiltrate them to a remote attacker-controlled server, potentially leading to unauthorized actions within the application. |
| In the Linux kernel, the following vulnerability has been resolved:
phy: ti: Fix missing sentinel for clk_div_table
_get_table_maxdiv() tries to access "clk_div_table" array out of bound
defined in phy-j721e-wiz.c. Add a sentinel entry to prevent
the following global-out-of-bounds error reported by enabling KASAN.
[ 9.552392] BUG: KASAN: global-out-of-bounds in _get_maxdiv+0xc0/0x148
[ 9.558948] Read of size 4 at addr ffff8000095b25a4 by task kworker/u4:1/38
[ 9.565926]
[ 9.567441] CPU: 1 PID: 38 Comm: kworker/u4:1 Not tainted 5.16.0-116492-gdaadb3bd0e8d-dirty #360
[ 9.576242] Hardware name: Texas Instruments J721e EVM (DT)
[ 9.581832] Workqueue: events_unbound deferred_probe_work_func
[ 9.587708] Call trace:
[ 9.590174] dump_backtrace+0x20c/0x218
[ 9.594038] show_stack+0x18/0x68
[ 9.597375] dump_stack_lvl+0x9c/0xd8
[ 9.601062] print_address_description.constprop.0+0x78/0x334
[ 9.606830] kasan_report+0x1f0/0x260
[ 9.610517] __asan_load4+0x9c/0xd8
[ 9.614030] _get_maxdiv+0xc0/0x148
[ 9.617540] divider_determine_rate+0x88/0x488
[ 9.622005] divider_round_rate_parent+0xc8/0x124
[ 9.626729] wiz_clk_div_round_rate+0x54/0x68
[ 9.631113] clk_core_determine_round_nolock+0x124/0x158
[ 9.636448] clk_core_round_rate_nolock+0x68/0x138
[ 9.641260] clk_core_set_rate_nolock+0x268/0x3a8
[ 9.645987] clk_set_rate+0x50/0xa8
[ 9.649499] cdns_sierra_phy_init+0x88/0x248
[ 9.653794] phy_init+0x98/0x108
[ 9.657046] cdns_pcie_enable_phy+0xa0/0x170
[ 9.661340] cdns_pcie_init_phy+0x250/0x2b0
[ 9.665546] j721e_pcie_probe+0x4b8/0x798
[ 9.669579] platform_probe+0x8c/0x108
[ 9.673350] really_probe+0x114/0x630
[ 9.677037] __driver_probe_device+0x18c/0x220
[ 9.681505] driver_probe_device+0xac/0x150
[ 9.685712] __device_attach_driver+0xec/0x170
[ 9.690178] bus_for_each_drv+0xf0/0x158
[ 9.694124] __device_attach+0x184/0x210
[ 9.698070] device_initial_probe+0x14/0x20
[ 9.702277] bus_probe_device+0xec/0x100
[ 9.706223] deferred_probe_work_func+0x124/0x180
[ 9.710951] process_one_work+0x4b0/0xbc0
[ 9.714983] worker_thread+0x74/0x5d0
[ 9.718668] kthread+0x214/0x230
[ 9.721919] ret_from_fork+0x10/0x20
[ 9.725520]
[ 9.727032] The buggy address belongs to the variable:
[ 9.732183] clk_div_table+0x24/0x440 |
| Mattermost Mobile Apps versions <=2.22.0 fail to properly handle specially crafted attachment names, which allows an attacker to crash the mobile app for any user who opened a channel containing the specially crafted attachment |
| Mattermost Mobile versions <=2.22.0 fail to properly handle posts with attachments containing fields that cannot be cast to a String, which allows an attacker to cause the mobile to crash via creating and sending such a post to a channel. |
| A weak authentication in Fortinet FortiManager Cloud, FortiAnalyzer versions 7.6.0 through 7.6.1, 7.4.1 through 7.4.3, FortiAnalyzer Cloud versions 7.4.1 through 7.4.3, FortiManager versions 7.6.0 through 7.6.1, 7.4.1 through 7.4.3, FortiManager Cloud versions 7.4.1 through 7.4.3 allows attacker to execute unauthorized code or commands via a brute-force attack. |
| A security flaw has been discovered in vim up to 9.1.1615. Affected by this vulnerability is the function main of the file src/xxd/xxd.c of the component xxd. The manipulation results in buffer overflow. The attack requires a local approach. The exploit has been released to the public and may be exploited. Upgrading to version 9.1.1616 addresses this issue. The patch is identified as eeef7c77436a78cd27047b0f5fa6925d56de3cb0. It is recommended to upgrade the affected component. |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix data corruption after conversion from inline format
Commit 6dbf7bb55598 ("fs: Don't invalidate page buffers in
block_write_full_page()") uncovered a latent bug in ocfs2 conversion
from inline inode format to a normal inode format.
The code in ocfs2_convert_inline_data_to_extents() attempts to zero out
the whole cluster allocated for file data by grabbing, zeroing, and
dirtying all pages covering this cluster. However these pages are
beyond i_size, thus writeback code generally ignores these dirty pages
and no blocks were ever actually zeroed on the disk.
This oversight was fixed by commit 693c241a5f6a ("ocfs2: No need to zero
pages past i_size.") for standard ocfs2 write path, inline conversion
path was apparently forgotten; the commit log also has a reasoning why
the zeroing actually is not needed.
After commit 6dbf7bb55598, things became worse as writeback code stopped
invalidating buffers on pages beyond i_size and thus these pages end up
with clean PageDirty bit but with buffers attached to these pages being
still dirty. So when a file is converted from inline format, then
writeback triggers, and then the file is grown so that these pages
become valid, the invalid dirtiness state is preserved,
mark_buffer_dirty() does nothing on these pages (buffers are already
dirty) but page is never written back because it is clean. So data
written to these pages is lost once pages are reclaimed.
Simple reproducer for the problem is:
xfs_io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \
-c "pwrite 4000 2000" ocfs2_file
After unmounting and mounting the fs again, you can observe that end of
'ocfs2_file' has lost its contents.
Fix the problem by not doing the pointless zeroing during conversion
from inline format similarly as in the standard write path.
[akpm@linux-foundation.org: fix whitespace, per Joseph] |
| Improper Handling of Length Parameter Inconsistency vulnerability in Mitsubishi Electric Corporation MELSEC-Q Series Q03UDVCPU, Q04UDVCPU, Q06UDVCPU, Q13UDVCPU, Q26UDVCPU, Q04UDPVCPU, Q06UDPVCPU, Q13UDPVCPU, and Q26UDPVCPU with the first 5 digits of serial No. "24082" to "27081" allows a remote attacker to cause an integer underflow by sending specially crafted packets to the affected product to stop Ethernet communication and the execution of control programs on the product, when the user authentication function is enabled. The user authentication function is enabled by default only when settings are configured by GX Works2, which complies with the Cybersecurity Law of the People's Republic of China, and is normally disabled. |
