| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Xorcom CompletePBX is vulnerable to an authenticated path traversal, allowing for arbitrary file reads via the Backup and Restore functionality.This issue affects CompletePBX: through 5.2.35. |
| Xorcom CompletePBX is vulnerable to a reflected cross-site scripting (XSS) in the administrative control panel.
This issue affects CompletePBX: all versions up to and prior to 5.2.35 |
| Xorcom CompletePBX is vulnerable to a path traversal via the Diagnostics reporting module, which will allow reading of arbitrary files and additionally delete any retrieved file in place of the expected report.
This issue affects CompletePBX: all versions up to and prior to 5.2.35 |
| dstack is a software development kit (SDK) to simplify the deployment of arbitrary containerized apps into trusted execution environments. In versions of dstack prior to 0.5.4, a malicious host may provide a crafted LUKS2 data volume to a dstack CVM for use as the `/data` mount. The guest will open the volume and write secret data using a volume key known to the attacker, causing disclosure of Wireguard keys and other secret information. The attacker can also pre-load data on the device, which could potentially compromise guest execution. LUKS2 volume metadata is not authenticated and supports null key-encryption algorithms, allowing an attacker to create a volume such that the volume opens (cryptsetup open) without error using any passphrase or token, records all writes in plaintext (or ciphertext with an attacker-known key), and/or contains arbitrary data chosen by the attacker. Version 0.5.4 of dstack contains a patch that addresses LUKS headers. |
| Constellation is the first Confidential Kubernetes. The Constellation CVM image uses LUKS2-encrypted volumes for persistent storage. When opening an encrypted storage device, the CVM uses the libcryptsetup function crypt_activate_by_passhrase. If the VM is successful in opening the partition with the disk encryption key, it treats the volume as confidential. However, due to the unsafe handling of null keyslot algorithms in the cryptsetup 2.8.1, it is possible that the opened volume is not encrypted at all. Cryptsetup prior to version 2.8.1 does not report an error when processing LUKS2-formatted disks that use the cipher_null-ecb algorithm in the keyslot encryption field. This vulnerability is fixed in 2.24.0. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: 8852a: rfk: fix div 0 exception
The DPK is a kind of RF calibration whose algorithm is to fine tune
parameters and calibrate, and check the result. If the result isn't good
enough, it could adjust parameters and try again.
This issue is to read and show the result, but it could be a negative
calibration result that causes divisor 0 and core dump. So, fix it by
phy_div() that does division only if divisor isn't zero; otherwise,
zero is adopted.
divide error: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 728 Comm: wpa_supplicant Not tainted 5.10.114-16019-g462a1661811a #1 <HASH:d024 28>
RIP: 0010:rtw8852a_dpk+0x14ae/0x288f [rtw89_core]
RSP: 0018:ffffa9bb412a7520 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 00000000000180fc RDI: ffffa141d01023c0
RBP: ffffa9bb412a76a0 R08: 0000000000001319 R09: 00000000ffffff92
R10: ffffffffc0292de3 R11: ffffffffc00d2f51 R12: 0000000000000000
R13: ffffa141d01023c0 R14: ffffffffc0290250 R15: ffffa141d0102638
FS: 00007fa99f5c2740(0000) GS:ffffa142e5e80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000013e8e010 CR3: 0000000110d2c000 CR4: 0000000000750ee0
PKRU: 55555554
Call Trace:
rtw89_core_sta_add+0x95/0x9c [rtw89_core <HASH:d239 29>]
rtw89_ops_sta_state+0x5d/0x108 [rtw89_core <HASH:d239 29>]
drv_sta_state+0x115/0x66f [mac80211 <HASH:81fe 30>]
sta_info_insert_rcu+0x45c/0x713 [mac80211 <HASH:81fe 30>]
sta_info_insert+0xf/0x1b [mac80211 <HASH:81fe 30>]
ieee80211_prep_connection+0x9d6/0xb0c [mac80211 <HASH:81fe 30>]
ieee80211_mgd_auth+0x2aa/0x352 [mac80211 <HASH:81fe 30>]
cfg80211_mlme_auth+0x160/0x1f6 [cfg80211 <HASH:00cd 31>]
nl80211_authenticate+0x2e5/0x306 [cfg80211 <HASH:00cd 31>]
genl_rcv_msg+0x371/0x3a1
? nl80211_stop_sched_scan+0xe5/0xe5 [cfg80211 <HASH:00cd 31>]
? genl_rcv+0x36/0x36
netlink_rcv_skb+0x8a/0xf9
genl_rcv+0x28/0x36
netlink_unicast+0x27b/0x3a0
netlink_sendmsg+0x2aa/0x469
sock_sendmsg_nosec+0x49/0x4d
____sys_sendmsg+0xe5/0x213
__sys_sendmsg+0xec/0x157
? syscall_enter_from_user_mode+0xd7/0x116
do_syscall_64+0x43/0x55
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fa99f6e689b |
| In the Linux kernel, the following vulnerability has been resolved:
rcutorture: Fix ksoftirqd boosting timing and iteration
The RCU priority boosting can fail in two situations:
1) If (nr_cpus= > maxcpus=), which means if the total number of CPUs
is higher than those brought online at boot, then torture_onoff() may
later bring up CPUs that weren't online on boot. Now since rcutorture
initialization only boosts the ksoftirqds of the CPUs that have been
set online on boot, the CPUs later set online by torture_onoff won't
benefit from the boost, making RCU priority boosting fail.
2) The ksoftirqd kthreads are boosted after the creation of
rcu_torture_boost() kthreads, which opens a window large enough for these
rcu_torture_boost() kthreads to wait (despite running at FIFO priority)
for ksoftirqds that are still running at SCHED_NORMAL priority.
The issues can trigger for example with:
./kvm.sh --configs TREE01 --kconfig "CONFIG_RCU_BOOST=y"
[ 34.968561] rcu-torture: !!!
[ 34.968627] ------------[ cut here ]------------
[ 35.014054] WARNING: CPU: 4 PID: 114 at kernel/rcu/rcutorture.c:1979 rcu_torture_stats_print+0x5ad/0x610
[ 35.052043] Modules linked in:
[ 35.069138] CPU: 4 PID: 114 Comm: rcu_torture_sta Not tainted 5.18.0-rc1 #1
[ 35.096424] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
[ 35.154570] RIP: 0010:rcu_torture_stats_print+0x5ad/0x610
[ 35.198527] Code: 63 1b 02 00 74 02 0f 0b 48 83 3d 35 63 1b 02 00 74 02 0f 0b 48 83 3d 21 63 1b 02 00 74 02 0f 0b 48 83 3d 0d 63 1b 02 00 74 02 <0f> 0b 83 eb 01 0f 8e ba fc ff ff 0f 0b e9 b3 fc ff f82
[ 37.251049] RSP: 0000:ffffa92a0050bdf8 EFLAGS: 00010202
[ 37.277320] rcu: De-offloading 8
[ 37.290367] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001
[ 37.290387] RDX: 0000000000000000 RSI: 00000000ffffbfff RDI: 00000000ffffffff
[ 37.290398] RBP: 000000000000007b R08: 0000000000000000 R09: c0000000ffffbfff
[ 37.290407] R10: 000000000000002a R11: ffffa92a0050bc18 R12: ffffa92a0050be20
[ 37.290417] R13: ffffa92a0050be78 R14: 0000000000000000 R15: 000000000001bea0
[ 37.290427] FS: 0000000000000000(0000) GS:ffff96045eb00000(0000) knlGS:0000000000000000
[ 37.290448] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 37.290460] CR2: 0000000000000000 CR3: 000000001dc0c000 CR4: 00000000000006e0
[ 37.290470] Call Trace:
[ 37.295049] <TASK>
[ 37.295065] ? preempt_count_add+0x63/0x90
[ 37.295095] ? _raw_spin_lock_irqsave+0x12/0x40
[ 37.295125] ? rcu_torture_stats_print+0x610/0x610
[ 37.295143] rcu_torture_stats+0x29/0x70
[ 37.295160] kthread+0xe3/0x110
[ 37.295176] ? kthread_complete_and_exit+0x20/0x20
[ 37.295193] ret_from_fork+0x22/0x30
[ 37.295218] </TASK>
Fix this with boosting the ksoftirqds kthreads from the boosting
hotplug callback itself and before the boosting kthreads are created. |
| In the Linux kernel, the following vulnerability has been resolved:
media: tw686x: Fix memory leak in tw686x_video_init
video_device_alloc() allocates memory for vdev,
when video_register_device() fails, it doesn't release the memory and
leads to memory leak, call video_device_release() to fix this. |
| In the Linux kernel, the following vulnerability has been resolved:
net: hinic: avoid kernel hung in hinic_get_stats64()
When using hinic device as a bond slave device, and reading device stats
of master bond device, the kernel may hung.
The kernel panic calltrace as follows:
Kernel panic - not syncing: softlockup: hung tasks
Call trace:
native_queued_spin_lock_slowpath+0x1ec/0x31c
dev_get_stats+0x60/0xcc
dev_seq_printf_stats+0x40/0x120
dev_seq_show+0x1c/0x40
seq_read_iter+0x3c8/0x4dc
seq_read+0xe0/0x130
proc_reg_read+0xa8/0xe0
vfs_read+0xb0/0x1d4
ksys_read+0x70/0xfc
__arm64_sys_read+0x20/0x30
el0_svc_common+0x88/0x234
do_el0_svc+0x2c/0x90
el0_svc+0x1c/0x30
el0_sync_handler+0xa8/0xb0
el0_sync+0x148/0x180
And the calltrace of task that actually caused kernel hungs as follows:
__switch_to+124
__schedule+548
schedule+72
schedule_timeout+348
__down_common+188
__down+24
down+104
hinic_get_stats64+44 [hinic]
dev_get_stats+92
bond_get_stats+172 [bonding]
dev_get_stats+92
dev_seq_printf_stats+60
dev_seq_show+24
seq_read_iter+964
seq_read+220
proc_reg_read+164
vfs_read+172
ksys_read+108
__arm64_sys_read+28
el0_svc_common+132
do_el0_svc+40
el0_svc+24
el0_sync_handler+164
el0_sync+324
When getting device stats from bond, kernel will call bond_get_stats().
It first holds the spinlock bond->stats_lock, and then call
hinic_get_stats64() to collect hinic device's stats.
However, hinic_get_stats64() calls `down(&nic_dev->mgmt_lock)` to
protect its critical section, which may schedule current task out.
And if system is under high pressure, the task cannot be woken up
immediately, which eventually triggers kernel hung panic.
Since previous patch has replaced hinic_dev.tx_stats/rx_stats with local
variable in hinic_get_stats64(), there is nothing need to be protected
by lock, so just removing down()/up() is ok. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm/mdp5: Fix global state lock backoff
We need to grab the lock after the early return for !hwpipe case.
Otherwise, we could have hit contention yet still returned 0.
Fixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flagged
in CI:
WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154
Modules linked in:
CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G W 5.19.0-rc2-15930-g875cc8bc536a #1
Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_modeset_lock+0xf8/0x154
lr : drm_atomic_get_private_obj_state+0x84/0x170
sp : ffff80000cfab6a0
x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00
x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58
x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001
x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038
x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0
x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47
x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610
x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000
x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029
x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58
Call trace:
drm_modeset_lock+0xf8/0x154
drm_atomic_get_private_obj_state+0x84/0x170
mdp5_get_global_state+0x54/0x6c
mdp5_pipe_release+0x2c/0xd4
mdp5_plane_atomic_check+0x2ec/0x414
drm_atomic_helper_check_planes+0xd8/0x210
drm_atomic_helper_check+0x54/0xb0
...
---[ end trace 0000000000000000 ]---
drm_modeset_lock attempting to lock a contended lock without backoff:
drm_modeset_lock+0x148/0x154
mdp5_get_global_state+0x30/0x6c
mdp5_pipe_release+0x2c/0xd4
mdp5_plane_atomic_check+0x290/0x414
drm_atomic_helper_check_planes+0xd8/0x210
drm_atomic_helper_check+0x54/0xb0
drm_atomic_check_only+0x4b0/0x8f4
drm_atomic_commit+0x68/0xe0
Patchwork: https://patchwork.freedesktop.org/patch/492701/ |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: mt76x02u: fix possible memory leak in __mt76x02u_mcu_send_msg
Free the skb if mt76u_bulk_msg fails in __mt76x02u_mcu_send_msg routine. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: hisilicon/sec - don't sleep when in softirq
When kunpeng920 encryption driver is used to deencrypt and decrypt
packets during the softirq, it is not allowed to use mutex lock. The
kernel will report the following error:
BUG: scheduling while atomic: swapper/57/0/0x00000300
Call trace:
dump_backtrace+0x0/0x1e4
show_stack+0x20/0x2c
dump_stack+0xd8/0x140
__schedule_bug+0x68/0x80
__schedule+0x728/0x840
schedule+0x50/0xe0
schedule_preempt_disabled+0x18/0x24
__mutex_lock.constprop.0+0x594/0x5dc
__mutex_lock_slowpath+0x1c/0x30
mutex_lock+0x50/0x60
sec_request_init+0x8c/0x1a0 [hisi_sec2]
sec_process+0x28/0x1ac [hisi_sec2]
sec_skcipher_crypto+0xf4/0x1d4 [hisi_sec2]
sec_skcipher_encrypt+0x1c/0x30 [hisi_sec2]
crypto_skcipher_encrypt+0x2c/0x40
crypto_authenc_encrypt+0xc8/0xfc [authenc]
crypto_aead_encrypt+0x2c/0x40
echainiv_encrypt+0x144/0x1a0 [echainiv]
crypto_aead_encrypt+0x2c/0x40
esp_output_tail+0x348/0x5c0 [esp4]
esp_output+0x120/0x19c [esp4]
xfrm_output_one+0x25c/0x4d4
xfrm_output_resume+0x6c/0x1fc
xfrm_output+0xac/0x3c0
xfrm4_output+0x64/0x130
ip_build_and_send_pkt+0x158/0x20c
tcp_v4_send_synack+0xdc/0x1f0
tcp_conn_request+0x7d0/0x994
tcp_v4_conn_request+0x58/0x6c
tcp_v6_conn_request+0xf0/0x100
tcp_rcv_state_process+0x1cc/0xd60
tcp_v4_do_rcv+0x10c/0x250
tcp_v4_rcv+0xfc4/0x10a4
ip_protocol_deliver_rcu+0xf4/0x200
ip_local_deliver_finish+0x58/0x70
ip_local_deliver+0x68/0x120
ip_sublist_rcv_finish+0x70/0x94
ip_list_rcv_finish.constprop.0+0x17c/0x1d0
ip_sublist_rcv+0x40/0xb0
ip_list_rcv+0x140/0x1dc
__netif_receive_skb_list_core+0x154/0x28c
__netif_receive_skb_list+0x120/0x1a0
netif_receive_skb_list_internal+0xe4/0x1f0
napi_complete_done+0x70/0x1f0
gro_cell_poll+0x9c/0xb0
napi_poll+0xcc/0x264
net_rx_action+0xd4/0x21c
__do_softirq+0x130/0x358
irq_exit+0x11c/0x13c
__handle_domain_irq+0x88/0xf0
gic_handle_irq+0x78/0x2c0
el1_irq+0xb8/0x140
arch_cpu_idle+0x18/0x40
default_idle_call+0x5c/0x1c0
cpuidle_idle_call+0x174/0x1b0
do_idle+0xc8/0x160
cpu_startup_entry+0x30/0x11c
secondary_start_kernel+0x158/0x1e4
softirq: huh, entered softirq 3 NET_RX 0000000093774ee4 with
preempt_count 00000100, exited with fffffe00? |
| In the Linux kernel, the following vulnerability has been resolved:
kunit: executor: Fix a memory leak on failure in kunit_filter_tests
It's possible that memory allocation for 'filtered' will fail, but for the
copy of the suite to succeed. In this case, the copy could be leaked.
Properly free 'copy' in the error case for the allocation of 'filtered'
failing.
Note that there may also have been a similar issue in
kunit_filter_subsuites, before it was removed in "kunit: flatten
kunit_suite*** to kunit_suite** in .kunit_test_suites".
This was reported by clang-analyzer via the kernel test robot, here:
https://lore.kernel.org/all/c8073b8e-7b9e-0830-4177-87c12f16349c@intel.com/
And by smatch via Dan Carpenter and the kernel test robot:
https://lore.kernel.org/all/202207101328.ASjx88yj-lkp@intel.com/ |
| In the Linux kernel, the following vulnerability has been resolved:
perf/core: Handle buffer mapping fail correctly in perf_mmap()
After successful allocation of a buffer or a successful attachment to an
existing buffer perf_mmap() tries to map the buffer read only into the page
table. If that fails, the already set up page table entries are zapped, but
the other perf specific side effects of that failure are not handled. The
calling code just cleans up the VMA and does not invoke perf_mmap_close().
This leaks reference counts, corrupts user->vm accounting and also results
in an unbalanced invocation of event::event_mapped().
Cure this by moving the event::event_mapped() invocation before the
map_range() call so that on map_range() failure perf_mmap_close() can be
invoked without causing an unbalanced event::event_unmapped() call.
perf_mmap_close() undoes the reference counts and eventually frees buffers. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86/intel/pmt: fix a crashlog NULL pointer access
Usage of the intel_pmt_read() for binary sysfs, requires a pcidev. The
current use of the endpoint value is only valid for telemetry endpoint
usage.
Without the ep, the crashlog usage causes the following NULL pointer
exception:
BUG: kernel NULL pointer dereference, address: 0000000000000000
Oops: Oops: 0000 [#1] SMP NOPTI
RIP: 0010:intel_pmt_read+0x3b/0x70 [pmt_class]
Code:
Call Trace:
<TASK>
? sysfs_kf_bin_read+0xc0/0xe0
kernfs_fop_read_iter+0xac/0x1a0
vfs_read+0x26d/0x350
ksys_read+0x6b/0xe0
__x64_sys_read+0x1d/0x30
x64_sys_call+0x1bc8/0x1d70
do_syscall_64+0x6d/0x110
Augment struct intel_pmt_entry with a pointer to the pcidev to avoid
the NULL pointer exception. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: uvc: Initialize frame-based format color matching descriptor
Fix NULL pointer crash in uvcg_framebased_make due to uninitialized color
matching descriptor for frame-based format which was added in
commit f5e7bdd34aca ("usb: gadget: uvc: Allow creating new color matching
descriptors") that added handling for uncompressed and mjpeg format.
Crash is seen when userspace configuration (via configfs) does not
explicitly define the color matching descriptor. If color_matching is not
found, config_group_find_item() returns NULL. The code then jumps to
out_put_cm, where it calls config_item_put(color_matching);. If
color_matching is NULL, this will dereference a null pointer, leading to a
crash.
[ 2.746440] Unable to handle kernel NULL pointer dereference at virtual address 000000000000008c
[ 2.756273] Mem abort info:
[ 2.760080] ESR = 0x0000000096000005
[ 2.764872] EC = 0x25: DABT (current EL), IL = 32 bits
[ 2.771068] SET = 0, FnV = 0
[ 2.771069] EA = 0, S1PTW = 0
[ 2.771070] FSC = 0x05: level 1 translation fault
[ 2.771071] Data abort info:
[ 2.771072] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[ 2.771073] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 2.771074] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 2.771075] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000a3e59000
[ 2.771077] [000000000000008c] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[ 2.771081] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
[ 2.771084] Dumping ftrace buffer:
[ 2.771085] (ftrace buffer empty)
[ 2.771138] CPU: 7 PID: 486 Comm: ln Tainted: G W E 6.6.58-android15
[ 2.771139] Hardware name: Qualcomm Technologies, Inc. SunP QRD HDK (DT)
[ 2.771140] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 2.771141] pc : __uvcg_fill_strm+0x198/0x2cc
[ 2.771145] lr : __uvcg_iter_strm_cls+0xc8/0x17c
[ 2.771146] sp : ffffffc08140bbb0
[ 2.771146] x29: ffffffc08140bbb0 x28: ffffff803bc81380 x27: ffffff8023bbd250
[ 2.771147] x26: ffffff8023bbd250 x25: ffffff803c361348 x24: ffffff803d8e6768
[ 2.771148] x23: 0000000000000004 x22: 0000000000000003 x21: ffffffc08140bc48
[ 2.771149] x20: 0000000000000000 x19: ffffffc08140bc48 x18: ffffffe9f8cf4a00
[ 2.771150] x17: 000000001bf64ec3 x16: 000000001bf64ec3 x15: ffffff8023bbd250
[ 2.771151] x14: 000000000000000f x13: 004c4b40000f4240 x12: 000a2c2a00051615
[ 2.771152] x11: 000000000000004f x10: ffffffe9f76b40ec x9 : ffffffe9f7e389d0
[ 2.771153] x8 : ffffff803d0d31ce x7 : 000f4240000a2c2a x6 : 0005161500028b0a
[ 2.771154] x5 : ffffff803d0d31ce x4 : 0000000000000003 x3 : 0000000000000000
[ 2.771155] x2 : ffffffc08140bc50 x1 : ffffffc08140bc48 x0 : 0000000000000000
[ 2.771156] Call trace:
[ 2.771157] __uvcg_fill_strm+0x198/0x2cc
[ 2.771157] __uvcg_iter_strm_cls+0xc8/0x17c
[ 2.771158] uvcg_streaming_class_allow_link+0x240/0x290
[ 2.771159] configfs_symlink+0x1f8/0x630
[ 2.771161] vfs_symlink+0x114/0x1a0
[ 2.771163] do_symlinkat+0x94/0x28c
[ 2.771164] __arm64_sys_symlinkat+0x54/0x70
[ 2.771164] invoke_syscall+0x58/0x114
[ 2.771166] el0_svc_common+0x80/0xe0
[ 2.771168] do_el0_svc+0x1c/0x28
[ 2.771169] el0_svc+0x3c/0x70
[ 2.771172] el0t_64_sync_handler+0x68/0xbc
[ 2.771173] el0t_64_sync+0x1a8/0x1ac
Initialize color matching descriptor for frame-based format to prevent
NULL pointer crash by mirroring the handling done for uncompressed and
mjpeg formats. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: apple: validate feature-report field count to prevent NULL pointer dereference
A malicious HID device with quirk APPLE_MAGIC_BACKLIGHT can trigger a NULL
pointer dereference whilst the power feature-report is toggled and sent to
the device in apple_magic_backlight_report_set(). The power feature-report
is expected to have two data fields, but if the descriptor declares one
field then accessing field[1] and dereferencing it in
apple_magic_backlight_report_set() becomes invalid
since field[1] will be NULL.
An example of a minimal descriptor which can cause the crash is something
like the following where the report with ID 3 (power report) only
references a single 1-byte field. When hid core parses the descriptor it
will encounter the final feature tag, allocate a hid_report (all members
of field[] will be zeroed out), create field structure and populate it,
increasing the maxfield to 1. The subsequent field[1] access and
dereference causes the crash.
Usage Page (Vendor Defined 0xFF00)
Usage (0x0F)
Collection (Application)
Report ID (1)
Usage (0x01)
Logical Minimum (0)
Logical Maximum (255)
Report Size (8)
Report Count (1)
Feature (Data,Var,Abs)
Usage (0x02)
Logical Maximum (32767)
Report Size (16)
Report Count (1)
Feature (Data,Var,Abs)
Report ID (3)
Usage (0x03)
Logical Minimum (0)
Logical Maximum (1)
Report Size (8)
Report Count (1)
Feature (Data,Var,Abs)
End Collection
Here we see the KASAN splat when the kernel dereferences the
NULL pointer and crashes:
[ 15.164723] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN NOPTI
[ 15.165691] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[ 15.165691] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0 #31 PREEMPT(voluntary)
[ 15.165691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 15.165691] RIP: 0010:apple_magic_backlight_report_set+0xbf/0x210
[ 15.165691] Call Trace:
[ 15.165691] <TASK>
[ 15.165691] apple_probe+0x571/0xa20
[ 15.165691] hid_device_probe+0x2e2/0x6f0
[ 15.165691] really_probe+0x1ca/0x5c0
[ 15.165691] __driver_probe_device+0x24f/0x310
[ 15.165691] driver_probe_device+0x4a/0xd0
[ 15.165691] __device_attach_driver+0x169/0x220
[ 15.165691] bus_for_each_drv+0x118/0x1b0
[ 15.165691] __device_attach+0x1d5/0x380
[ 15.165691] device_initial_probe+0x12/0x20
[ 15.165691] bus_probe_device+0x13d/0x180
[ 15.165691] device_add+0xd87/0x1510
[...]
To fix this issue we should validate the number of fields that the
backlight and power reports have and if they do not have the required
number of fields then bail. |
| Redis is an open source, in-memory database that persists on disk. In versions starting from 7.0.0 to before 8.0.2, a stack-based buffer overflow exists in redis-check-aof due to the use of memcpy with strlen(filepath) when copying a user-supplied file path into a fixed-size stack buffer. This allows an attacker to overflow the stack and potentially achieve code execution. This issue has been patched in version 8.0.2. |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache DolphinScheduler.
The information exposed to unauthorized actors may include sensitive data such as database credentials.
Users who can't upgrade to the fixed version can also set environment variable `MANAGEMENT_ENDPOINTS_WEB_EXPOSURE_INCLUDE=health,metrics,prometheus` to workaround this, or add the following section in the `application.yaml` file
```
management:
endpoints:
web:
exposure:
include: health,metrics,prometheus
```
This issue affects Apache DolphinScheduler: from 3.0.0 before 3.0.2.
Users are recommended to upgrade to version 3.0.2, which fixes the issue. |
| Fugue is a unified interface for distributed computing that lets users execute Python, Pandas, and SQL code on Spark, Dask, and Ray with minimal rewrites. In version 0.9.2 and prior, there is a remote code execution vulnerability by pickle deserialization via FlaskRPCServer. The Fugue framework implements an RPC server system for distributed computing operations. In the core functionality of the RPC server implementation, I found that the _decode() function in fugue/rpc/flask.py directly uses cloudpickle.loads() to deserialize data without any sanitization. This creates a remote code execution vulnerability when malicious pickle data is processed by the RPC server. The vulnerability exists in the RPC communication mechanism where the client can send arbitrary serialized Python objects that will be deserialized on the server side, allowing attackers to execute arbitrary code on the victim's machine. This issue has been patched via commit 6f25326. |
