| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| GitHub cannot issue a CVE for this Security Advisory because this advisory includes information about more than one vulnerability.
According to [rule 4.2.11 of the CVE CNA rules](https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_4-2_CVE_ID_Assignment):
> 4.2.6 CNAs SHOULD assign different CVE IDs to separate Vulnerabilities, as determined using the guidance in [4.1](https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_4-1_Vulnerability_Determination).
> 4.2.11 CNAs SHOULD assign different CVE IDs to different, Independently Fixable Vulnerabilities.
You can move forward in one of two ways:
- If you agree that this Security Advisory concerns more than one independently fixable vulnerability, split each vulnerability into its own advisory and request one CVE for each vulnerability.
- If you do not agree that these vulnerabilities are independently fixable, resubmit the CVE request with a section clarifying how they are dependent and should have the same CVE.
Thank you for making the open source ecosystem more secure by fixing and responsibly disclosing these vulnerabilities. |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| An SQL injection vulnerability in Palo Alto Networks Expedition enables an authenticated attacker to reveal Expedition database contents, such as password hashes, usernames, device configurations, and device API keys. This vulnerability also enables attackers to create and read arbitrary files on the Expedition system. |
| A reflected cross-site scripting (XSS) vulnerability in Palo Alto Networks Expedition enables attackers to execute malicious JavaScript code in the context of an authenticated Expedition user’s browser if that authenticated user clicks a malicious link that allows phishing attacks and could lead to Expedition browser-session theft. |
| libuser has information disclosure when moving user's home directory |
| An arbitrary file deletion vulnerability in Palo Alto Networks Expedition enables an unauthenticated attacker to delete arbitrary files accessible to the www-data user on the host filesystem. |
| A wildcard expansion vulnerability in Palo Alto Networks Expedition allows an unauthenticated attacker to enumerate files on the host filesystem. |
| An OS command injection vulnerability in Palo Alto Networks Expedition enables an unauthenticated attacker to run arbitrary OS commands as the www-data user in Expedition, which results in the disclosure of usernames, cleartext passwords, device configurations, and device API keys for firewalls running PAN-OS software. |
| The communication protocol used between the
server process and the service control had a flaw that could lead to a local privilege escalation. |
| The communication protocol used between client
and server had a flaw that could be leveraged to execute a man in the middle attack. |
| The communication protocol used between client and server had a flaw that could lead to an authenticated user performing a remote code execution attack. |
| A vulnerability has been found in SourceCodester Clinics Patient Management System 1.0 and classified as critical. This vulnerability affects unknown code of the file /pms/ajax/get_packings.php. The manipulation of the argument medicine_id leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. |
| In the Linux kernel, the following vulnerability has been resolved:
thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash
When CPU 0 is offline and intel_powerclamp is used to inject
idle, it generates kernel BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687
caller is debug_smp_processor_id+0x17/0x20
CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57
Call Trace:
<TASK>
dump_stack_lvl+0x49/0x63
dump_stack+0x10/0x16
check_preemption_disabled+0xdd/0xe0
debug_smp_processor_id+0x17/0x20
powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp]
...
...
Here CPU 0 is the control CPU by default and changed to the current CPU,
if CPU 0 offlined. This check has to be performed under cpus_read_lock(),
hence the above warning.
Use get_cpu() instead of smp_processor_id() to avoid this BUG.
[ rjw: Subject edits ] |
| A vulnerability was found in HDF5 up to 1.14.6. It has been rated as critical. Affected by this issue is the function H5FL__blk_gc_list of the file src/H5FL.c. The manipulation of the argument H5FL_blk_head_t leads to use after free. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. |
| A vulnerability was found in HDF5 up to 1.14.6. It has been declared as problematic. Affected by this vulnerability is the function H5O_msg_flush of the file src/H5Omessage.c. The manipulation of the argument oh leads to heap-based buffer overflow. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. |
| A vulnerability, which was classified as critical, has been found in HDF5 up to 1.14.6. Affected by this issue is the function H5FS__sect_find_node of the file H5FSsection.c. The manipulation leads to heap-based buffer overflow. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm: fix use-after-free on probe deferral
The bridge counter was never reset when tearing down the DRM device so
that stale pointers to deallocated structures would be accessed on the
next tear down (e.g. after a second late bind deferral).
Given enough bridges and a few probe deferrals this could currently also
lead to data beyond the bridge array being corrupted.
Patchwork: https://patchwork.freedesktop.org/patch/502665/ |
| In the Linux kernel, the following vulnerability has been resolved:
null_blk: fix poll request timeout handling
When doing io_uring benchmark on /dev/nullb0, it's easy to crash the
kernel if poll requests timeout triggered, as reported by David. [1]
BUG: kernel NULL pointer dereference, address: 0000000000000008
Workqueue: kblockd blk_mq_timeout_work
RIP: 0010:null_timeout_rq+0x4e/0x91
Call Trace:
? null_timeout_rq+0x4e/0x91
blk_mq_handle_expired+0x31/0x4b
bt_iter+0x68/0x84
? bt_tags_iter+0x81/0x81
__sbitmap_for_each_set.constprop.0+0xb0/0xf2
? __blk_mq_complete_request_remote+0xf/0xf
bt_for_each+0x46/0x64
? __blk_mq_complete_request_remote+0xf/0xf
? percpu_ref_get_many+0xc/0x2a
blk_mq_queue_tag_busy_iter+0x14d/0x18e
blk_mq_timeout_work+0x95/0x127
process_one_work+0x185/0x263
worker_thread+0x1b5/0x227
This is indeed a race problem between null_timeout_rq() and null_poll().
null_poll() null_timeout_rq()
spin_lock(&nq->poll_lock)
list_splice_init(&nq->poll_list, &list)
spin_unlock(&nq->poll_lock)
while (!list_empty(&list))
req = list_first_entry()
list_del_init()
...
blk_mq_add_to_batch()
// req->rq_next = NULL
spin_lock(&nq->poll_lock)
// rq->queuelist->next == NULL
list_del_init(&rq->queuelist)
spin_unlock(&nq->poll_lock)
Fix these problems by setting requests state to MQ_RQ_COMPLETE under
nq->poll_lock protection, in which null_timeout_rq() can safely detect
this race and early return.
Note this patch just fix the kernel panic when request timeout happen.
[1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/ |
| In the Linux kernel, the following vulnerability has been resolved:
zram: fix slot write race condition
Parallel concurrent writes to the same zram index result in leaked
zsmalloc handles. Schematically we can have something like this:
CPU0 CPU1
zram_slot_lock()
zs_free(handle)
zram_slot_lock()
zram_slot_lock()
zs_free(handle)
zram_slot_lock()
compress compress
handle = zs_malloc() handle = zs_malloc()
zram_slot_lock
zram_set_handle(handle)
zram_slot_lock
zram_slot_lock
zram_set_handle(handle)
zram_slot_lock
Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done
too early. In fact, we need to reset zram entry right before we set its
new handle, all under the same slot lock scope. |
