| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: host: Fix race between unprepare and queue_buf
A client driver may use mhi_unprepare_from_transfer() to quiesce
incoming data during the client driver's tear down. The client driver
might also be processing data at the same time, resulting in a call to
mhi_queue_buf() which will invoke mhi_gen_tre(). If mhi_gen_tre() runs
after mhi_unprepare_from_transfer() has torn down the channel, a panic
will occur due to an invalid dereference leading to a page fault.
This occurs because mhi_gen_tre() does not verify the channel state
after locking it. Fix this by having mhi_gen_tre() confirm the channel
state is valid, or return error to avoid accessing deinitialized data.
[mani: added stable tag] |
| In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi_parser: refactor hfi packet parsing logic
words_count denotes the number of words in total payload, while data
points to payload of various property within it. When words_count
reaches last word, data can access memory beyond the total payload. This
can lead to OOB access. With this patch, the utility api for handling
individual properties now returns the size of data consumed. Accordingly
remaining bytes are calculated before parsing the payload, thereby
eliminates the OOB access possibilities. |
| In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi_parser: add check to avoid out of bound access
There is a possibility that init_codecs is invoked multiple times during
manipulated payload from video firmware. In such case, if codecs_count
can get incremented to value more than MAX_CODEC_NUM, there can be OOB
access. Reset the count so that it always starts from beginning. |
| In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video
firmware. Firmware can modify this value to an invalid large value. In
such situation, empty_space will be bigger than the space actually
available. Since new_wr_idx is not checked, so the following code will
result in an OOB write.
...
qsize = qhdr->q_size
if (wr_idx >= rd_idx)
empty_space = qsize - (wr_idx - rd_idx)
....
if (new_wr_idx < qsize) {
memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while
reading and writing packets into the queue. |
| In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add a check to handle OOB in sfr region
sfr->buf_size is in shared memory and can be modified by malicious user.
OOB write is possible when the size is made higher than actual sfr data
buffer. Cap the size to allocated size for such cases. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Fix workqueue crash in cma_netevent_work_handler
struct rdma_cm_id has member "struct work_struct net_work"
that is reused for enqueuing cma_netevent_work_handler()s
onto cma_wq.
Below crash[1] can occur if more than one call to
cma_netevent_callback() occurs in quick succession,
which further enqueues cma_netevent_work_handler()s for the
same rdma_cm_id, overwriting any previously queued work-item(s)
that was just scheduled to run i.e. there is no guarantee
the queued work item may run between two successive calls
to cma_netevent_callback() and the 2nd INIT_WORK would overwrite
the 1st work item (for the same rdma_cm_id), despite grabbing
id_table_lock during enqueue.
Also drgn analysis [2] indicates the work item was likely overwritten.
Fix this by moving the INIT_WORK() to __rdma_create_id(),
so that it doesn't race with any existing queue_work() or
its worker thread.
[1] Trimmed crash stack:
=============================================
BUG: kernel NULL pointer dereference, address: 0000000000000008
kworker/u256:6 ... 6.12.0-0...
Workqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm)
RIP: 0010:process_one_work+0xba/0x31a
Call Trace:
worker_thread+0x266/0x3a0
kthread+0xcf/0x100
ret_from_fork+0x31/0x50
ret_from_fork_asm+0x1a/0x30
=============================================
[2] drgn crash analysis:
>>> trace = prog.crashed_thread().stack_trace()
>>> trace
(0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15)
(1) __crash_kexec (kernel/crash_core.c:122:4)
(2) panic (kernel/panic.c:399:3)
(3) oops_end (arch/x86/kernel/dumpstack.c:382:3)
...
(8) process_one_work (kernel/workqueue.c:3168:2)
(9) process_scheduled_works (kernel/workqueue.c:3310:3)
(10) worker_thread (kernel/workqueue.c:3391:4)
(11) kthread (kernel/kthread.c:389:9)
Line workqueue.c:3168 for this kernel version is in process_one_work():
3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);
>>> trace[8]["work"]
*(struct work_struct *)0xffff92577d0a21d8 = {
.data = (atomic_long_t){
.counter = (s64)536870912, <=== Note
},
.entry = (struct list_head){
.next = (struct list_head *)0xffff924d075924c0,
.prev = (struct list_head *)0xffff924d075924c0,
},
.func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280,
}
Suspicion is that pwq is NULL:
>>> trace[8]["pwq"]
(struct pool_workqueue *)<absent>
In process_one_work(), pwq is assigned from:
struct pool_workqueue *pwq = get_work_pwq(work);
and get_work_pwq() is:
static struct pool_workqueue *get_work_pwq(struct work_struct *work)
{
unsigned long data = atomic_long_read(&work->data);
if (data & WORK_STRUCT_PWQ)
return work_struct_pwq(data);
else
return NULL;
}
WORK_STRUCT_PWQ is 0x4:
>>> print(repr(prog['WORK_STRUCT_PWQ']))
Object(prog, 'enum work_flags', value=4)
But work->data is 536870912 which is 0x20000000.
So, get_work_pwq() returns NULL and we crash in process_one_work():
3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);
============================================= |
| In the Linux kernel, the following vulnerability has been resolved:
virtiofs: add filesystem context source name check
In certain scenarios, for example, during fuzz testing, the source
name may be NULL, which could lead to a kernel panic. Therefore, an
extra check for the source name should be added. |
| Jenkins JDepend Plugin 1.3.1 and earlier includes an outdated version of JDepend Maven Plugin that does not configure its XML parser to prevent XML external entity (XXE) attacks. |
| Totolink LR350 v9.3.5u.6369_B20220309 was discovered to contain a stack overflow via the http_host parameter in the sub_426EF8 function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
| Totolink LR350 v9.3.5u.6369_B20220309 was discovered to contain a stack overflow via the password parameter in the sub_426EF8 function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
| Totolink LR350 v9.3.5u.6369_B20220309 was discovered to contain a stack overflow via the ssid parameter in the sub_425400 function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
| Totolink LR350 v9.3.5u.6369_B20220309 was discovered to contain a stack overflow via the ssid parameter in the sub_421BAC function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
| Totolink A7000R v9.1.0u.6115_B20201022 was discovered to contain a stack overflow via the ssid5g parameter in the sub_4222E0 function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
| Totolink A7000R v9.1.0u.6115_B20201022 was discovered to contain a stack overflow via the ssid5g parameter in the urldecode function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
| Totolink A7000R v9.1.0u.6115_B20201022 was discovered to contain a stack overflow via the wifiOff parameter in the sub_421A04 function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
| Totolink LR350 v9.3.5u.6369_B20220309 was discovered to contain a stack overflow via the wifiOff parameter in the sub_4232EC function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
| Totolink LR350 v9.3.5u.6369_B20220309 was discovered to contain a stack overflow via the ssid parameter in the sub_42396C function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
| Totolink LR350 v9.3.5u.6369_B20220309 was discovered to contain a stack overflow via the ssid parameter in the sub_422880 function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
| Totolink A7000R v9.1.0u.6115_B20201022 was discovered to contain a stack overflow via the ssid5g parameter in the sub_421CF0 function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
| Tenda AX-3 v16.03.12.10_CN was discovered to contain a stack overflow via the deviceId parameter in the get_parentControl_list_Info function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
