| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: fix some memleaks in gssx_dec_option_array
The creds and oa->data need to be freed in the error-handling paths after
their allocation. So this patch add these deallocations in the
corresponding paths. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix NULL domain on device release
In the kdump kernel, the IOMMU operates in deferred_attach mode. In this
mode, info->domain may not yet be assigned by the time the release_device
function is called. It leads to the following crash in the crash kernel:
BUG: kernel NULL pointer dereference, address: 000000000000003c
...
RIP: 0010:do_raw_spin_lock+0xa/0xa0
...
_raw_spin_lock_irqsave+0x1b/0x30
intel_iommu_release_device+0x96/0x170
iommu_deinit_device+0x39/0xf0
__iommu_group_remove_device+0xa0/0xd0
iommu_bus_notifier+0x55/0xb0
notifier_call_chain+0x5a/0xd0
blocking_notifier_call_chain+0x41/0x60
bus_notify+0x34/0x50
device_del+0x269/0x3d0
pci_remove_bus_device+0x77/0x100
p2sb_bar+0xae/0x1d0
...
i801_probe+0x423/0x740
Use the release_domain mechanism to fix it. The scalable mode context
entry which is not part of release domain should be cleared in
release_device(). |
| In the Linux kernel, the following vulnerability has been resolved:
media: go7007: fix a memleak in go7007_load_encoder
In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without
a deallocation thereafter. After the following call chain:
saa7134_go7007_init
|-> go7007_boot_encoder
|-> go7007_load_encoder
|-> kfree(go)
go is freed and thus bounce is leaked. |
| In the Linux kernel, the following vulnerability has been resolved:
media: ttpci: fix two memleaks in budget_av_attach
When saa7146_register_device and saa7146_vv_init fails, budget_av_attach
should free the resources it allocates, like the error-handling of
ttpci_budget_init does. Besides, there are two fixme comment refers to
such deallocations. |
| In the Linux kernel, the following vulnerability has been resolved:
backlight: hx8357: Fix potential NULL pointer dereference
The "im" pins are optional. Add missing check in the hx8357_probe(). |
| In the Linux kernel, the following vulnerability has been resolved:
thermal/drivers/mediatek/lvts_thermal: Fix a memory leak in an error handling path
If devm_krealloc() fails, then 'efuse' is leaking.
So free it to avoid a leak. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: sun8i-ce - Fix use after free in unprepare
sun8i_ce_cipher_unprepare should be called before
crypto_finalize_skcipher_request, because client callbacks may
immediately free memory, that isn't needed anymore. But it will be
used by unprepare after free. Before removing prepare/unprepare
callbacks it was handled by crypto engine in crypto_finalize_request.
Usually that results in a pointer dereference problem during a in
crypto selftest.
Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000030
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=000000004716d000
[0000000000000030] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] SMP
This problem is detected by KASAN as well.
==================================================================
BUG: KASAN: slab-use-after-free in sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce]
Read of size 8 at addr ffff00000dcdc040 by task 1c15000.crypto-/373
Hardware name: Pine64 PinePhone (1.2) (DT)
Call trace:
dump_backtrace+0x9c/0x128
show_stack+0x20/0x38
dump_stack_lvl+0x48/0x60
print_report+0xf8/0x5d8
kasan_report+0x90/0xd0
__asan_load8+0x9c/0xc0
sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce]
crypto_pump_work+0x354/0x620 [crypto_engine]
kthread_worker_fn+0x244/0x498
kthread+0x168/0x178
ret_from_fork+0x10/0x20
Allocated by task 379:
kasan_save_stack+0x3c/0x68
kasan_set_track+0x2c/0x40
kasan_save_alloc_info+0x24/0x38
__kasan_kmalloc+0xd4/0xd8
__kmalloc+0x74/0x1d0
alg_test_skcipher+0x90/0x1f0
alg_test+0x24c/0x830
cryptomgr_test+0x38/0x60
kthread+0x168/0x178
ret_from_fork+0x10/0x20
Freed by task 379:
kasan_save_stack+0x3c/0x68
kasan_set_track+0x2c/0x40
kasan_save_free_info+0x38/0x60
__kasan_slab_free+0x100/0x170
slab_free_freelist_hook+0xd4/0x1e8
__kmem_cache_free+0x15c/0x290
kfree+0x74/0x100
kfree_sensitive+0x80/0xb0
alg_test_skcipher+0x12c/0x1f0
alg_test+0x24c/0x830
cryptomgr_test+0x38/0x60
kthread+0x168/0x178
ret_from_fork+0x10/0x20
The buggy address belongs to the object at ffff00000dcdc000
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 64 bytes inside of
freed 256-byte region [ffff00000dcdc000, ffff00000dcdc100) |
| In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Fix NULL pointer dereference in tb_port_update_credits()
Olliver reported that his system crashes when plugging in Thunderbolt 1
device:
BUG: kernel NULL pointer dereference, address: 0000000000000020
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:tb_port_do_update_credits+0x1b/0x130 [thunderbolt]
Call Trace:
<TASK>
? __die+0x23/0x70
? page_fault_oops+0x171/0x4e0
? exc_page_fault+0x7f/0x180
? asm_exc_page_fault+0x26/0x30
? tb_port_do_update_credits+0x1b/0x130
? tb_switch_update_link_attributes+0x83/0xd0
tb_switch_add+0x7a2/0xfe0
tb_scan_port+0x236/0x6f0
tb_handle_hotplug+0x6db/0x900
process_one_work+0x171/0x340
worker_thread+0x27b/0x3a0
? __pfx_worker_thread+0x10/0x10
kthread+0xe5/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x31/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
</TASK>
This is due the fact that some Thunderbolt 1 devices only have one lane
adapter. Fix this by checking for the lane 1 before we read its credits. |
| In the Linux kernel, the following vulnerability has been resolved:
tmpfs: fix race on handling dquot rbtree
A syzkaller reproducer found a race while attempting to remove dquot
information from the rb tree.
Fetching the rb_tree root node must also be protected by the
dqopt->dqio_sem, otherwise, giving the right timing, shmem_release_dquot()
will trigger a warning because it couldn't find a node in the tree, when
the real reason was the root node changing before the search starts:
Thread 1 Thread 2
- shmem_release_dquot() - shmem_{acquire,release}_dquot()
- fetch ROOT - Fetch ROOT
- acquire dqio_sem
- wait dqio_sem
- do something, triger a tree rebalance
- release dqio_sem
- acquire dqio_sem
- start searching for the node, but
from the wrong location, missing
the node, and triggering a warning. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: fix double module refcount decrement
Once the discipline is associated with the device, deleting the device
takes care of decrementing the module's refcount. Doing it manually on
this error path causes refcount to artificially decrease on each error
while it should just stay the same. |
| In the Linux kernel, the following vulnerability has been resolved:
cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value
cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
and return 0 in case of error.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
| In the Linux kernel, the following vulnerability has been resolved:
libbpf: Use OPTS_SET() macro in bpf_xdp_query()
When the feature_flags and xdp_zc_max_segs fields were added to the libbpf
bpf_xdp_query_opts, the code writing them did not use the OPTS_SET() macro.
This causes libbpf to write to those fields unconditionally, which means
that programs compiled against an older version of libbpf (with a smaller
size of the bpf_xdp_query_opts struct) will have its stack corrupted by
libbpf writing out of bounds.
The patch adding the feature_flags field has an early bail out if the
feature_flags field is not part of the opts struct (via the OPTS_HAS)
macro, but the patch adding xdp_zc_max_segs does not. For consistency, this
fix just changes the assignments to both fields to use the OPTS_SET()
macro. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7925e: fix use-after-free in free_irq()
From commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test
to make sure the shared irq handler should be able to handle the unexpected
event after deregistration. For this case, let's apply MT76_REMOVED flag to
indicate the device was removed and do not run into the resource access
anymore. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: brcm80211: handle pmk_op allocation failure
The kzalloc() in brcmf_pmksa_v3_op() will return null if the
physical memory has run out. As a result, if we dereference
the null value, the null pointer dereference bug will happen.
Return -ENOMEM from brcmf_pmksa_v3_op() if kzalloc() fails
for pmk_op. |
| In the Linux kernel, the following vulnerability has been resolved:
nfp: flower: handle acti_netdevs allocation failure
The kmalloc_array() in nfp_fl_lag_do_work() will return null, if
the physical memory has run out. As a result, if we dereference
the acti_netdevs, the null pointer dereference bugs will happen.
This patch adds a check to judge whether allocation failure occurs.
If it happens, the delayed work will be rescheduled and try again. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()'
Tell snprintf() to store at most 10 bytes in the output buffer
instead of 30.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10 |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'
The 'stream' pointer is used in dcn10_set_output_transfer_func() before
the check if 'stream' is NULL.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875) |
| In the Linux kernel, the following vulnerability has been resolved:
media: edia: dvbdev: fix a use-after-free
In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed
in several error-handling paths. However, *pdvbdev is not set to NULL
after dvbdev's deallocation, causing use-after-frees in many places,
for example, in the following call chain:
budget_register
|-> dvb_dmxdev_init
|-> dvb_register_device
|-> dvb_dmxdev_release
|-> dvb_unregister_device
|-> dvb_remove_device
|-> dvb_device_put
|-> kref_put
When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in
dvb_register_device) could point to memory that had been freed in
dvb_register_device. Thereafter, this pointer is transferred to
kref_put and triggering a use-after-free. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini()
Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL
before the call to dc_enable_dmub_notifications(), check
beforehand to ensure there will not be a possible NULL-ptr-deref
there.
Also, since commit 1e88eb1b2c25 ("drm/amd/display: Drop
CONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in
'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy().
Clean up by combining them all under one 'if'.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add 'replay' NULL check in 'edp_set_replay_allow_active()'
In the first if statement, we're checking if 'replay' is NULL. But in
the second if statement, we're not checking if 'replay' is NULL again
before calling replay->funcs->replay_set_power_opt().
if (replay == NULL && force_static)
return false;
...
if (link->replay_settings.replay_feature_enabled &&
replay->funcs->replay_set_power_opt) {
replay->funcs->replay_set_power_opt(replay, *power_opts, panel_inst);
link->replay_settings.replay_power_opt_active = *power_opts;
}
If 'replay' is NULL, this will cause a null pointer dereference.
Fixes the below found by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_edp_panel_control.c:895 edp_set_replay_allow_active() error: we previously assumed 'replay' could be null (see line 887) |
