| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
media: cx23885: Fix a null-ptr-deref bug in buffer_prepare() and buffer_finish()
When the driver calls cx23885_risc_buffer() to prepare the buffer, the
function call dma_alloc_coherent may fail, resulting in a empty buffer
risc->cpu. Later when we free the buffer or access the buffer, null ptr
deref is triggered.
This bug is similar to the following one:
https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71.
We believe the bug can be also dynamically triggered from user side.
Similarly, we fix this by checking the return value of cx23885_risc_buffer()
and the value of risc->cpu before buffer free. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: qla4xxx: Add length check when parsing nlattrs
There are three places that qla4xxx parses nlattrs:
- qla4xxx_set_chap_entry()
- qla4xxx_iface_set_param()
- qla4xxx_sysfs_ddb_set_param()
and each of them directly converts the nlattr to specific pointer of
structure without length checking. This could be dangerous as those
attributes are not validated and a malformed nlattr (e.g., length 0) could
result in an OOB read that leaks heap dirty data.
Add the nla_len check before accessing the nlattr data and return EINVAL if
the length check fails. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: free iio for atombios when driver shutdown
Fix below kmemleak when unload radeon driver:
unreferenced object 0xffff9f8608ede200 (size 512):
comm "systemd-udevd", pid 326, jiffies 4294682822 (age 716.338s)
hex dump (first 32 bytes):
00 00 00 00 c4 aa ec aa 14 ab 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000062fadebe>] kmem_cache_alloc_trace+0x2f1/0x500
[<00000000b6883cea>] atom_parse+0x117/0x230 [radeon]
[<00000000158c23fd>] radeon_atombios_init+0xab/0x170 [radeon]
[<00000000683f672e>] si_init+0x57/0x750 [radeon]
[<00000000566cc31f>] radeon_device_init+0x559/0x9c0 [radeon]
[<0000000046efabb3>] radeon_driver_load_kms+0xc1/0x1a0 [radeon]
[<00000000b5155064>] drm_dev_register+0xdd/0x1d0
[<0000000045fec835>] radeon_pci_probe+0xbd/0x100 [radeon]
[<00000000e69ecca3>] pci_device_probe+0xe1/0x160
[<0000000019484b76>] really_probe.part.0+0xc1/0x2c0
[<000000003f2649da>] __driver_probe_device+0x96/0x130
[<00000000231c5bb1>] driver_probe_device+0x24/0xf0
[<0000000000a42377>] __driver_attach+0x77/0x190
[<00000000d7574da6>] bus_for_each_dev+0x7f/0xd0
[<00000000633166d2>] driver_attach+0x1e/0x30
[<00000000313b05b8>] bus_add_driver+0x12c/0x1e0
iio was allocated in atom_index_iio() called by atom_parse(),
but it doesn't got released when the dirver is shutdown.
Fix this kmemleak by free it in radeon_atombios_fini(). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: drop all currently held locks if deadlock happens
If vc4_hdmi_reset_link() returns -EDEADLK, it means that a deadlock
happened in the locking context. This situation should be addressed by
dropping all currently held locks and block until the contended lock
becomes available. Currently, vc4 is not dealing with the deadlock
properly, producing the following output when PROVE_LOCKING is enabled:
[ 825.612809] ------------[ cut here ]------------
[ 825.612852] WARNING: CPU: 1 PID: 116 at drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x60/0x68 [drm]
[ 825.613458] Modules linked in: 8021q mrp garp stp llc
raspberrypi_cpufreq brcmfmac brcmutil crct10dif_ce hci_uart cfg80211
btqca btbcm bluetooth vc4 raspberrypi_hwmon snd_soc_hdmi_codec cec
clk_raspberrypi ecdh_generic drm_display_helper ecc rfkill
drm_dma_helper drm_kms_helper pwm_bcm2835 bcm2835_thermal bcm2835_rng
rng_core i2c_bcm2835 drm fuse ip_tables x_tables ipv6
[ 825.613735] CPU: 1 PID: 116 Comm: kworker/1:2 Tainted: G W 6.1.0-rc6-01399-g941aae326315 #3
[ 825.613759] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
[ 825.613777] Workqueue: events output_poll_execute [drm_kms_helper]
[ 825.614038] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 825.614063] pc : drm_modeset_drop_locks+0x60/0x68 [drm]
[ 825.614603] lr : drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper]
[ 825.614829] sp : ffff800008313bf0
[ 825.614844] x29: ffff800008313bf0 x28: ffffcd7778b8b000 x27: 0000000000000000
[ 825.614883] x26: 0000000000000001 x25: 0000000000000001 x24: ffff677cc35c2758
[ 825.614920] x23: ffffcd7707d01430 x22: ffffcd7707c3edc7 x21: 0000000000000001
[ 825.614958] x20: 0000000000000000 x19: ffff800008313c10 x18: 000000000000b6d3
[ 825.614995] x17: ffffcd777835e214 x16: ffffcd7777cef870 x15: fffff81000000000
[ 825.615033] x14: 0000000000000000 x13: 0000000000000099 x12: 0000000000000002
[ 825.615070] x11: 72917988020af800 x10: 72917988020af800 x9 : 72917988020af800
[ 825.615108] x8 : ffff677cc665e0a8 x7 : d00a8c180000110c x6 : ffffcd77774c0054
[ 825.615145] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000
[ 825.615181] x2 : ffff677cc55e1880 x1 : ffffcd7777cef8ec x0 : ffff800008313c10
[ 825.615219] Call trace:
[ 825.615232] drm_modeset_drop_locks+0x60/0x68 [drm]
[ 825.615773] drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper]
[ 825.616003] output_poll_execute+0xe4/0x224 [drm_kms_helper]
[ 825.616233] process_one_work+0x2b4/0x618
[ 825.616264] worker_thread+0x24c/0x464
[ 825.616288] kthread+0xec/0x110
[ 825.616310] ret_from_fork+0x10/0x20
[ 825.616335] irq event stamp: 7634
[ 825.616349] hardirqs last enabled at (7633): [<ffffcd777831ee90>] _raw_spin_unlock_irq+0x3c/0x78
[ 825.616384] hardirqs last disabled at (7634): [<ffffcd7778315a78>] __schedule+0x134/0x9f0
[ 825.616411] softirqs last enabled at (7630): [<ffffcd7707aacea0>] local_bh_enable+0x4/0x30 [ipv6]
[ 825.617019] softirqs last disabled at (7618): [<ffffcd7707aace70>] local_bh_disable+0x4/0x30 [ipv6]
[ 825.617586] ---[ end trace 0000000000000000 ]---
Therefore, deal with the deadlock as suggested by [1], using the
function drm_modeset_backoff().
[1] https://docs.kernel.org/gpu/drm-kms.html?highlight=kms#kms-locking |
| In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix potential memory leak in rtw_init_drv_sw()
In rtw_init_drv_sw(), there are various init functions are called to
populate the padapter structure and some checks for their return value.
However, except for the first one error path, the other five error paths
do not properly release the previous allocated resources, which leads to
various memory leaks.
This patch fixes them and keeps the success and error separate.
Note that these changes keep the form of `rtw_init_drv_sw()` in
"drivers/staging/r8188eu/os_dep/os_intfs.c". As there is no proper device
to test with, no runtime testing was performed. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/chrome: cros_usbpd_notify: Fix error handling in cros_usbpd_notify_init()
The following WARNING message was given when rmmod cros_usbpd_notify:
Unexpected driver unregister!
WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0
Modules linked in: cros_usbpd_notify(-)
CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24
...
Call Trace:
<TASK>
cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify]
__x64_sys_delete_module+0x3c7/0x570
? __ia32_sys_delete_module+0x570/0x570
? lock_is_held_type+0xe3/0x140
? syscall_enter_from_user_mode+0x17/0x50
? rcu_read_lock_sched_held+0xa0/0xd0
? syscall_enter_from_user_mode+0x1c/0x50
do_syscall_64+0x37/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f333fe9b1b7
The reason is that the cros_usbpd_notify_init() does not check the return
value of platform_driver_register(), and the cros_usbpd_notify can
install successfully even if platform_driver_register() failed.
Fix by checking the return value of platform_driver_register() and
unregister cros_usbpd_notify_plat_driver when it failed. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/binfmt_elf: Fix memory leak in load_elf_binary()
There is a memory leak reported by kmemleak:
unreferenced object 0xffff88817104ef80 (size 224):
comm "xfs_admin", pid 47165, jiffies 4298708825 (age 1333.476s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60 a8 b3 00 81 88 ff ff a8 10 5a 00 81 88 ff ff `.........Z.....
backtrace:
[<ffffffff819171e1>] __alloc_file+0x21/0x250
[<ffffffff81918061>] alloc_empty_file+0x41/0xf0
[<ffffffff81948cda>] path_openat+0xea/0x3d30
[<ffffffff8194ec89>] do_filp_open+0x1b9/0x290
[<ffffffff8192660e>] do_open_execat+0xce/0x5b0
[<ffffffff81926b17>] open_exec+0x27/0x50
[<ffffffff81a69250>] load_elf_binary+0x510/0x3ed0
[<ffffffff81927759>] bprm_execve+0x599/0x1240
[<ffffffff8192a997>] do_execveat_common.isra.0+0x4c7/0x680
[<ffffffff8192b078>] __x64_sys_execve+0x88/0xb0
[<ffffffff83bbf0a5>] do_syscall_64+0x35/0x80
If "interp_elf_ex" fails to allocate memory in load_elf_binary(),
the program will take the "out_free_ph" error handing path,
resulting in "interpreter" file resource is not released.
Fix it by adding an error handing path "out_free_file", which will
release the file resource when "interp_elf_ex" failed to allocate
memory. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix null ndlp ptr dereference in abnormal exit path for GFT_ID
An error case exit from lpfc_cmpl_ct_cmd_gft_id() results in a call to
lpfc_nlp_put() with a null pointer to a nodelist structure.
Changed lpfc_cmpl_ct_cmd_gft_id() to initialize nodelist pointer upon
entry. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: fix leaking uninitialized memory in fast-commit journal
When space at the end of fast-commit journal blocks is unused, make sure
to zero it out so that uninitialized memory is not leaked to disk. |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7915: Fix PCI device refcount leak in mt7915_pci_init_hif2()
As comment of pci_get_device() says, it returns a pci_device with its
refcount increased. We need to call pci_dev_put() to decrease the
refcount. Save the return value of pci_get_device() and call
pci_dev_put() to decrease the refcount. |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/52xx: Fix a resource leak in an error handling path
The error handling path of mpc52xx_lpbfifo_probe() has a request_irq()
that is not balanced by a corresponding free_irq().
Add the missing call, as already done in the remove function. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()
Fix a NULL pointer crash that occurs when we are freeing the socket at the
same time we access it via sysfs.
The problem is that:
1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take
the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold()
does a get on the "struct sock".
2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put
on the "struct socket" and that does __sock_release() which sets the
sock->ops to NULL.
3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then
call kernel_getpeername() which accesses the NULL sock->ops.
Above we do a get on the "struct sock", but we needed a get on the "struct
socket". Originally, we just held the frwd_lock the entire time but in
commit bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock while
calling getpeername()") we switched to refcount based because the network
layer changed and started taking a mutex in that path, so we could no
longer hold the frwd_lock.
Instead of trying to maintain multiple refcounts, this just has us use a
mutex for accessing the socket in the interface code paths. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm/hdmi: fix memory corruption with too many bridges
Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.
Patchwork: https://patchwork.freedesktop.org/patch/502670/ |
| In the Linux kernel, the following vulnerability has been resolved:
mtd: core: Fix refcount error in del_mtd_device()
del_mtd_device() will call of_node_put() to mtd_get_of_node(mtd), which
is mtd->dev.of_node. However, memset(&mtd->dev, 0) is called before
of_node_put(). As the result, of_node_put() won't do anything in
del_mtd_device(), and causes the refcount leak.
del_mtd_device()
memset(&mtd->dev, 0, sizeof(mtd->dev) # clear mtd->dev
of_node_put()
mtd_get_of_node(mtd) # mtd->dev is cleared, can't locate of_node
# of_node_put(NULL) won't do anything
Fix the error by caching the pointer of the device_node.
OF: ERROR: memory leak, expected refcount 1 instead of 2,
of_node_get()/of_node_put() unbalanced - destroy cset entry: attach
overlay node /spi/spi-sram@0
CPU: 3 PID: 275 Comm: python3 Tainted: G N 6.1.0-rc3+ #54
0d8a1edddf51f172ff5226989a7565c6313b08e2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x67/0x83
kobject_get+0x155/0x160
of_node_get+0x1f/0x30
of_fwnode_get+0x43/0x70
fwnode_handle_get+0x54/0x80
fwnode_get_nth_parent+0xc9/0xe0
fwnode_full_name_string+0x3f/0xa0
device_node_string+0x30f/0x750
pointer+0x598/0x7a0
vsnprintf+0x62d/0x9b0
...
cfs_overlay_release+0x30/0x90
config_item_release+0xbe/0x1a0
config_item_put+0x5e/0x80
configfs_rmdir+0x3bd/0x540
vfs_rmdir+0x18c/0x320
do_rmdir+0x198/0x330
__x64_sys_rmdir+0x2c/0x40
do_syscall_64+0x37/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
[<miquel.raynal@bootlin.com>: Light reword of the commit log] |
| In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix a use-after-free in nouveau_gem_prime_import_sg_table()
nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code
back to the caller. On failures, ttm will call nouveau_bo_del_ttm() and
free the memory.Thus, when nouveau_bo_init() returns an error, the gem
object has already been released. Then the call to nouveau_bo_ref() will
use the freed "nvbo->bo" and lead to a use-after-free bug.
We should delete the call to nouveau_bo_ref() to avoid the use-after-free. |
| In the Linux kernel, the following vulnerability has been resolved:
gpiolib: cdev: fix NULL-pointer dereferences
There are several places where we can crash the kernel by requesting
lines, unbinding the GPIO device, then calling any of the system calls
relevant to the GPIO character device's annonymous file descriptors:
ioctl(), read(), poll().
While I observed it with the GPIO simulator, it will also happen for any
of the GPIO devices that can be hot-unplugged - for instance any HID GPIO
expander (e.g. CP2112).
This affects both v1 and v2 uAPI.
This fixes it partially by checking if gdev->chip is not NULL but it
doesn't entirely remedy the situation as we still have a race condition
in which another thread can remove the device after the check. |
| In the Linux kernel, the following vulnerability has been resolved:
net: sched: cake: fix null pointer access issue when cake_init() fails
When the default qdisc is cake, if the qdisc of dev_queue fails to be
inited during mqprio_init(), cake_reset() is invoked to clear
resources. In this case, the tins is NULL, and it will cause gpf issue.
The process is as follows:
qdisc_create_dflt()
cake_init()
q->tins = kvcalloc(...) --->failed, q->tins is NULL
...
qdisc_put()
...
cake_reset()
...
cake_dequeue_one()
b = &q->tins[...] --->q->tins is NULL
The following is the Call Trace information:
general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:cake_dequeue_one+0xc9/0x3c0
Call Trace:
<TASK>
cake_reset+0xb1/0x140
qdisc_reset+0xed/0x6f0
qdisc_destroy+0x82/0x4c0
qdisc_put+0x9e/0xb0
qdisc_create_dflt+0x2c3/0x4a0
mqprio_init+0xa71/0x1760
qdisc_create+0x3eb/0x1000
tc_modify_qdisc+0x408/0x1720
rtnetlink_rcv_msg+0x38e/0xac0
netlink_rcv_skb+0x12d/0x3a0
netlink_unicast+0x4a2/0x740
netlink_sendmsg+0x826/0xcc0
sock_sendmsg+0xc5/0x100
____sys_sendmsg+0x583/0x690
___sys_sendmsg+0xe8/0x160
__sys_sendmsg+0xbf/0x160
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f89e5122d04
</TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: Fix crash on hci_create_cis_sync
When attempting to connect multiple ISO sockets without using
DEFER_SETUP may result in the following crash:
BUG: KASAN: null-ptr-deref in hci_create_cis_sync+0x18b/0x2b0
Read of size 2 at addr 0000000000000036 by task kworker/u3:1/50
CPU: 0 PID: 50 Comm: kworker/u3:1 Not tainted
6.0.0-rc7-02243-gb84a13ff4eda #4373
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
BIOS 1.16.0-1.fc36 04/01/2014
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
<TASK>
dump_stack_lvl+0x19/0x27
kasan_report+0xbc/0xf0
? hci_create_cis_sync+0x18b/0x2b0
hci_create_cis_sync+0x18b/0x2b0
? get_link_mode+0xd0/0xd0
? __ww_mutex_lock_slowpath+0x10/0x10
? mutex_lock+0xe0/0xe0
? get_link_mode+0xd0/0xd0
hci_cmd_sync_work+0x111/0x190
process_one_work+0x427/0x650
worker_thread+0x87/0x750
? process_one_work+0x650/0x650
kthread+0x14e/0x180
? kthread_exit+0x50/0x50
ret_from_fork+0x22/0x30
</TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
ARC: mm: fix leakage of memory allocated for PTE
Since commit d9820ff ("ARC: mm: switch pgtable_t back to struct page *")
a memory leakage problem occurs. Memory allocated for page table entries
not released during process termination. This issue can be reproduced by
a small program that allocates a large amount of memory. After several
runs, you'll see that the amount of free memory has reduced and will
continue to reduce after each run. All ARC CPUs are effected by this
issue. The issue was introduced since the kernel stable release v5.15-rc1.
As described in commit d9820ff after switch pgtable_t back to struct
page *, a pointer to "struct page" and appropriate functions are used to
allocate and free a memory page for PTEs, but the pmd_pgtable macro hasn't
changed and returns the direct virtual address from the PMD (PGD) entry.
Than this address used as a parameter in the __pte_free() and as a result
this function couldn't release memory page allocated for PTEs.
Fix this issue by changing the pmd_pgtable macro and returning pointer to
struct page. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: tegra20: Fix refcount leak in tegra20_clock_init
of_find_matching_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak. |
