| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| phpMyFAQ before 4.1.9 and 4.2.0-alpha before 4.2.0-beta does not require the current password when changing an account e-mail in the user control panel (UserController::updateData, api/user/data/update), checking only the session and CSRF token. An attacker with a hijacked session can set the e-mail to their own mailbox and use the password-reset flow to take over non-2FA accounts, including superadmin. |
| phpMyFAQ before 4.1.9 and 4.2.0-alpha before 4.2.0-beta contains an account enumeration vulnerability that allows unauthenticated attackers to confirm registered display names and emails via a distinct HTTP 409 response. Attackers can submit guest comments to the comment create endpoint with candidate user and mail values to link names to emails for targeted phishing. |
| A weakness has been identified in aircheng-org iWebShop-5 up to 5.16. The impacted element is the function IController::redirect of the file plugins/_userInfo/_userInfo.php of the component Login Redirect. This manipulation of the argument callback causes open redirect. The attack can be initiated remotely. The exploit has been made available to the public and could be used for attacks. The project was informed of the problem early through an issue report but has not responded yet. |
| The Post Voting System WordPress plugin through 1.0 does not properly sanitize and escape a parameter before using it in a SQL query, allowing unauthenticated users to perform SQL injection attacks. |
| phpMyFAQ from 4.2.0-alpha.2 before 4.2.0-beta lacks brute-force lockout in the removeTwofactorConfig() 2FA removal endpoint, allowing authenticated attackers to guess TOTP codes without limit. Attackers holding a hijacked session and CSRF token can repeatedly POST guesses to /api/user/remove-twofactor to permanently disable the victim's 2FA. |
| A vulnerability was found in diem-project diem up to 5.1.3. This vulnerability affects unknown code of the file dmCorePlugin/lib/data/dmDataLoad.php. Performing a manipulation results in use of default password. The attack is possible to be carried out remotely. The exploit has been made public and could be used. It is suggested to update the configuration settings. The project was informed of the problem early through an issue report but has not responded yet. |
| Out-of-bounds read in DNS Server allows an authorized attacker to disclose information over a network. |
| Out-of-bounds read in DNS Server allows an authorized attacker to disclose information over a network. |
| Use after free in Windows Broadcast DVR User Service allows an authorized attacker to elevate privileges locally. |
| In the Linux kernel, the following vulnerability has been resolved:
module: fix lost error code from codetag_load_module()
If codetag_load_module() fails, err is not set to reflect the failure
and load_module() returns 0 after the module has been torn down.
Also, if the module is a livepatch, mod->klp_info allocated by
copy_module_elf() leaks on this error path. Free it via a new
livepatch_cleanup label. |
| Use after free in Windows Broadcast DVR User Service allows an authorized attacker to elevate privileges locally. |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| Use after free in Windows Broadcast DVR User Service allows an authorized attacker to elevate privileges locally. |
| ip-address before 10.7.4 allows a denial of service (CPU consumption from quadratic complexity, and application stall) via many % characters in input reaching a function call that uses the Address6 constructor. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix AF_XDP TX timestamp teardown NULL dereference
During XSK TX queue teardown, outstanding descriptors are completed
without a CQE. If one requested a TX timestamp, the completion path
passes that NULL CQE to mlx5e_xsk_fill_timestamp(), which dereferences
it.
Return zero when no CQE is available, indicating that teardown did not
produce a TX timestamp. |
| In the Linux kernel, the following vulnerability has been resolved:
block: reject polled dio with user integrity metadata
IOCB_HAS_METADATA leaves iocb->private as a uio_meta, while
iocb_bio_iopoll() expects a bio. Since 2729a60bbfb9, metadata I/O
always uses __blkdev_direct_IO(), which never publishes the bio for
polling, so IOPOLL calls bio_poll() on the uio_meta.
Reproducer: io_uring IOPOLL plus a PI attribute on an integrity device
(scsi_debug dif=1 dix=1). KASAN reports:
Oops: general protection fault, probably for non-canonical
address 0xdffffc0000000004
KASAN: null-ptr-deref in range
[0x0000000000000020-0x0000000000000027]
RIP: 0010:bio_poll+0x9d/0x4b0
Call Trace:
iocb_bio_iopoll+0x5b/0x80
io_uring_classic_poll+0xf3/0x140
io_do_iopoll+0x4e3/0xc00
io_iopoll_check+0x275/0x560
__do_sys_io_uring_enter+0x2e5/0x720
Return -EOPNOTSUPP when HIPRI is combined with user metadata. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE
__hif_usb_tx() dequeues up to MAX_TX_AGGR_NUM (20) frames into a
single tx_buf of MAX_TX_BUF_SIZE (32768) bytes, limiting the batch
by record count but never by cumulative byte length.
With large frames (MTU 2304), 20 aggregated frames of 2292 bytes
each exceed the allocation (20 * 2296 = 45920 bytes), so the
memcpy() in the loop writes up to 13152 bytes past tx_buf->buf
before usb_submit_urb().
Peek the queue head and stop before copying any record that would
cross MAX_TX_BUF_SIZE, then dispatch the current batch. Leftover
skbs remain queued and are drained on the next URB completion.
The byte bound changes the loop's exit semantics: it can now exit
before i == tx_skb_cnt - 1. Stock only finalized tx_buf->len on
that last index (len += offset), so an early break would submit a
URB holding only the last record's length while every dequeued skb
is freed on completion, silently dropping frames. Make tx_buf->len
a running total and advance tx_buf->offset per record instead; the
stride round_up(nskb->len + 4, 4) is identical to the stock stride
when the loop runs to completion.
Tested on hardware with an MTU 2304 flood: the loop stops at
record 15 (len = 32144, offset = 32144, within 32768), no
oversized URB is submitted, and MTU 1500 pings pass 20/20. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: drop oversized fragments to avoid extra_len overflow
In ieee80211_rx_h_defragment(), fragment payloads are accumulated into
entry->extra_len as subsequent fragments arrive:
entry->extra_len += rx->skb->len;
When the final fragment arrives, the head fragment is dequeued, and
pskb_expand_head() is called with entry->extra_len to ensure sufficient
tailroom for all queued fragments before copying:
if (skb_tailroom(rx->skb) < entry->extra_len) {
if (unlikely(pskb_expand_head(rx->skb, 0, entry->extra_len,
GFP_ATOMIC))) {
...
}
}
while ((skb = __skb_dequeue(&entry->skb_list))) {
skb_put_data(rx->skb, skb->data, skb->len);
dev_kfree_skb(skb);
}
In commit 69f132236827 ("mac80211: shrink struct
ieee80211_fragment_entry"), entry->extra_len was narrowed from unsigned
int to u16 in order to reduce structure memory footprint.
However, an IEEE 802.11 frame sequence can contain up to 16 fragments
(frag numbers 0..15). If a sequence of large fragments arrives (e.g. from
a malicious peer or rogue AP), the sum of fragment lengths can exceed
65535 bytes (for example, 15 fragments of 4400 bytes total 66000 bytes).
Because extra_len is a u16, this addition overflows and wraps around
modulo 65536 (e.g. 66000 wraps to 464).
Consequently, pskb_expand_head() allocates only the truncated amount of
tailroom (or is skipped entirely if the head fragment already has >= 464
bytes of tailroom). When skb_put_data() subsequently iterates through the
queued skb list, it appends the full payload into the undersized buffer,
causing skb_put() to trigger skb_over_panic() and crash the kernel in
softirq context.
A legitimate MSDU in IEEE 802.11 is at most 2304 bytes (or up to 7935/11454
bytes for A-MSDU, which is not fragmented), well below U16_MAX.
Fix this without increasing the size of struct ieee80211_fragment_entry by
checking whether adding the incoming fragment length would exceed U16_MAX.
If so, purge the queued fragments and drop the frame.
[assign a separate drop reason] |
| In the Linux kernel, the following vulnerability has been resolved:
mtd: core: avoid double-free of OTP NVMEM device
If factory OTP setup fails after the user OTP NVMEM device has been
registered, mtd_otp_nvmem_add() unregisters the user device but leaves
mtd->otp_user_nvmem set. On an error, the caller unregisters it again.
For -EOPNOTSUPP, registration continues and normal teardown unregisters
it again.
Clear mtd->otp_user_nvmem after unregistering it. |
| In the Linux kernel, the following vulnerability has been resolved:
vt: selection: Fix unsigned underflow and slab-out-of-bounds read in paste_selection()
In paste_selection(), the loop copies min_t(unsigned int,
vc_sel.buf_len - pasted,tty->receive_room) bytes per iteration into
tty_ldisc_receive_buf() and increments pasted += count.
Because the selection mutex (vc_sel.lock) is dropped inside the loop
Whenever the line discipline buffer fills up and paste_selection()
sleeps on tty->write_wait, a concurrent TIOCLINUX (TIOCL_SETSEL) ioctl
can replace vc_sel.buffer with a shorter selection and reduce
vc_sel.buf_len below pasted.
When paste_selection() resumes, vc_sel.buf_len - pasted underflows as an
unsigned integer to a large positive value, causing
tty_ldisc_receive_buf(ld, vc_sel.buffer + pasted, NULL, count) to read
up to 4094 bytes out-of-bounds past the newly allocated vc_sel.buffer.
Fix this by terminating the loop when pasted >= vc_sel.buf_len.
Kernel stack trace (Linux 7.3.0-rc3):
==================================================================
BUG: KASAN: slab-out-of-bounds in n_tty_receive_buf_common+0xa01/0x1650
Read of size 4094 at addr ffff888101c58010 by task kworker/u17:1/65
Workqueue: events_unbound flush_to_ldisc
Call Trace:
<TASK>
dump_stack_lvl+0x70/0xa0
print_report+0x153/0x4c6
kasan_report+0xf1/0x120
kasan_check_range+0x11c/0x200
__asan_memcpy+0x29/0x70
n_tty_receive_buf_common+0xa01/0x1650
tty_ldisc_receive_buf+0x66/0x110
tty_port_default_receive_buf+0x6b/0xb0
flush_to_ldisc+0x1b4/0x410
process_one_work+0x6ff/0x1110
worker_thread+0x4a8/0xb70
kthread+0x307/0x3e0
ret_from_fork+0x3ed/0x680
</TASK>
================================================================== |
