| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
orangefs: Fix kmemleak in orangefs_prepare_debugfs_help_string()
When insert and remove the orangefs module, then debug_help_string will
be leaked:
unreferenced object 0xffff8881652ba000 (size 4096):
comm "insmod", pid 1701, jiffies 4294893639 (age 13218.530s)
hex dump (first 32 bytes):
43 6c 69 65 6e 74 20 44 65 62 75 67 20 4b 65 79 Client Debug Key
77 6f 72 64 73 20 61 72 65 20 75 6e 6b 6e 6f 77 words are unknow
backtrace:
[<0000000004e6f8e3>] kmalloc_trace+0x27/0xa0
[<0000000006f75d85>] orangefs_prepare_debugfs_help_string+0x5e/0x480 [orangefs]
[<0000000091270a2a>] _sub_I_65535_1+0x57/0xf70 [crc_itu_t]
[<000000004b1ee1a3>] do_one_initcall+0x87/0x2a0
[<000000001d0614ae>] do_init_module+0xdf/0x320
[<00000000efef068c>] load_module+0x2f98/0x3330
[<000000006533b44d>] __do_sys_finit_module+0x113/0x1b0
[<00000000a0da6f99>] do_syscall_64+0x35/0x80
[<000000007790b19b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
When remove the module, should always free debug_help_string. Should
always free the allocated buffer when change the free_debug_help_string. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: st: Fix memory leak in st_of_quadfs_setup()
If st_clk_register_quadfs_pll() fails, @lock should be freed before goto
@err_exit, otherwise will cause meory leak issue, fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix refcount leak in hns_roce_mmap
rdma_user_mmap_entry_get_pgoff() takes the reference.
Add missing rdma_user_mmap_entry_put() to release the reference.
Acked-by Haoyue Xu <xuhaoyue1@hisilicon.com> |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix memory leak in ocfs2_mount_volume()
There is a memory leak reported by kmemleak:
unreferenced object 0xffff88810cc65e60 (size 32):
comm "mount.ocfs2", pid 23753, jiffies 4302528942 (age 34735.105s)
hex dump (first 32 bytes):
10 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8170f73d>] __kmalloc+0x4d/0x150
[<ffffffffa0ac3f51>] ocfs2_compute_replay_slots+0x121/0x330 [ocfs2]
[<ffffffffa0b65165>] ocfs2_check_volume+0x485/0x900 [ocfs2]
[<ffffffffa0b68129>] ocfs2_mount_volume.isra.0+0x1e9/0x650 [ocfs2]
[<ffffffffa0b7160b>] ocfs2_fill_super+0xe0b/0x1740 [ocfs2]
[<ffffffff818e1fe2>] mount_bdev+0x312/0x400
[<ffffffff819a086d>] legacy_get_tree+0xed/0x1d0
[<ffffffff818de82d>] vfs_get_tree+0x7d/0x230
[<ffffffff81957f92>] path_mount+0xd62/0x1760
[<ffffffff81958a5a>] do_mount+0xca/0xe0
[<ffffffff81958d3c>] __x64_sys_mount+0x12c/0x1a0
[<ffffffff82f26f15>] do_syscall_64+0x35/0x80
[<ffffffff8300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
This call stack is related to two problems. Firstly, the ocfs2 super uses
"replay_map" to trace online/offline slots, in order to recover offline
slots during recovery and mount. But when ocfs2_truncate_log_init()
returns an error in ocfs2_mount_volume(), the memory of "replay_map" will
not be freed in error handling path. Secondly, the memory of "replay_map"
will not be freed if d_make_root() returns an error in ocfs2_fill_super().
But the memory of "replay_map" will be freed normally when completing
recovery and mount in ocfs2_complete_mount_recovery().
Fix the first problem by adding error handling path to free "replay_map"
when ocfs2_truncate_log_init() fails. And fix the second problem by
calling ocfs2_free_replay_slots(osb) in the error handling path
"out_dismount". In addition, since ocfs2_free_replay_slots() is static,
it is necessary to remove its static attribute and declare it in header
file. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: smartpqi: Correct device removal for multi-actuator devices
Correct device count for multi-actuator drives which can cause kernel
panics. |
| In the Linux kernel, the following vulnerability has been resolved:
x86/xen: Fix memory leak in xen_init_lock_cpu()
In xen_init_lock_cpu(), the @name has allocated new string by kasprintf(),
if bind_ipi_to_irqhandler() fails, it should be freed, otherwise may lead
to a memory leak issue, fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
configfs: fix possible memory leak in configfs_create_dir()
kmemleak reported memory leaks in configfs_create_dir():
unreferenced object 0xffff888009f6af00 (size 192):
comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s)
backtrace:
kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)
new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163)
configfs_register_subsystem (fs/configfs/dir.c:1857)
basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic
do_one_initcall (init/main.c:1296)
do_init_module (kernel/module/main.c:2455)
...
unreferenced object 0xffff888003ba7180 (size 96):
comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s)
backtrace:
kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)
configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194)
configfs_make_dirent (fs/configfs/dir.c:248)
configfs_create_dir (fs/configfs/dir.c:296)
configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852)
configfs_register_subsystem (fs/configfs/dir.c:1881)
basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic
do_one_initcall (init/main.c:1296)
do_init_module (kernel/module/main.c:2455)
...
This is because the refcount is not correct in configfs_make_dirent().
For normal stage, the refcount is changing as:
configfs_register_subsystem()
configfs_create_dir()
configfs_make_dirent()
configfs_new_dirent() # set s_count = 1
dentry->d_fsdata = configfs_get(sd); # s_count = 2
...
configfs_unregister_subsystem()
configfs_remove_dir()
remove_dir()
configfs_remove_dirent() # s_count = 1
dput() ...
*dentry_unlink_inode()*
configfs_d_iput() # s_count = 0, release
However, if we failed in configfs_create():
configfs_register_subsystem()
configfs_create_dir()
configfs_make_dirent() # s_count = 2
...
configfs_create() # fail
->out_remove:
configfs_remove_dirent(dentry)
configfs_put(sd) # s_count = 1
return PTR_ERR(inode);
There is no inode in the error path, so the configfs_d_iput() is lost
and makes sd and fragment memory leaked.
To fix this, when we failed in configfs_create(), manually call
configfs_put(sd) to keep the refcount correct. |
| In the Linux kernel, the following vulnerability has been resolved:
acct: fix potential integer overflow in encode_comp_t()
The integer overflow is descripted with following codes:
> 317 static comp_t encode_comp_t(u64 value)
> 318 {
> 319 int exp, rnd;
......
> 341 exp <<= MANTSIZE;
> 342 exp += value;
> 343 return exp;
> 344 }
Currently comp_t is defined as type of '__u16', but the variable 'exp' is
type of 'int', so overflow would happen when variable 'exp' in line 343 is
greater than 65535. |
| In the Linux kernel, the following vulnerability has been resolved:
ipc: mqueue: fix possible memory leak in init_mqueue_fs()
commit db7cfc380900 ("ipc: Free mq_sysctls if ipc namespace creation
failed")
Here's a similar memory leak to the one fixed by the patch above.
retire_mq_sysctls need to be called when init_mqueue_fs fails after
setup_mq_sysctls. |
| In the Linux kernel, the following vulnerability has been resolved:
misc: ocxl: fix possible refcount leak in afu_ioctl()
eventfd_ctx_put need to be called to put the refcount that gotten by
eventfd_ctx_fdget when ocxl_irq_set_handler fails. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: do not run mt76u_status_worker if the device is not running
Fix the following NULL pointer dereference avoiding to run
mt76u_status_worker thread if the device is not running yet.
KASAN: null-ptr-deref in range
[0x0000000000000000-0x0000000000000007]
CPU: 0 PID: 98 Comm: kworker/u2:2 Not tainted 5.14.0+ #78 Hardware
name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Workqueue: mt76 mt76u_tx_status_data
RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0
Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00
48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f>
b6
04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7
RSP: 0018:ffffc900005af988 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a
RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c
R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8
R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28
FS: 0000000000000000(0000) GS:ffff88811aa00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
mt76x02_send_tx_status+0x1d2/0xeb0
mt76x02_tx_status_data+0x8e/0xd0
mt76u_tx_status_data+0xe1/0x240
process_one_work+0x92b/0x1460
worker_thread+0x95/0xe00
kthread+0x3a1/0x480
ret_from_fork+0x1f/0x30
Modules linked in:
--[ end trace 8df5d20fc5040f65 ]--
RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0
Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00
48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f>
b6
04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7
RSP: 0018:ffffc900005af988 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a
RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c
R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8
R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28
FS: 0000000000000000(0000) GS:ffff88811aa00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0
PKRU: 55555554
Moreover move stat_work schedule out of the for loop. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: silence the warning when evicting inode with dioread_nolock
When evicting an inode with default dioread_nolock, it could be raced by
the unwritten extents converting kworker after writeback some new
allocated dirty blocks. It convert unwritten extents to written, the
extents could be merged to upper level and free extent blocks, so it
could mark the inode dirty again even this inode has been marked
I_FREEING. But the inode->i_io_list check and warning in
ext4_evict_inode() missing this corner case. Fortunately,
ext4_evict_inode() will wait all extents converting finished before this
check, so it will not lead to inode use-after-free problem, every thing
is OK besides this warning. The WARN_ON_ONCE was originally designed
for finding inode use-after-free issues in advance, but if we add
current dioread_nolock case in, it will become not quite useful, so fix
this warning by just remove this check.
======
WARNING: CPU: 7 PID: 1092 at fs/ext4/inode.c:227
ext4_evict_inode+0x875/0xc60
...
RIP: 0010:ext4_evict_inode+0x875/0xc60
...
Call Trace:
<TASK>
evict+0x11c/0x2b0
iput+0x236/0x3a0
do_unlinkat+0x1b4/0x490
__x64_sys_unlinkat+0x4c/0xb0
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7fa933c1115b
======
rm kworker
ext4_end_io_end()
vfs_unlink()
ext4_unlink()
ext4_convert_unwritten_io_end_vec()
ext4_convert_unwritten_extents()
ext4_map_blocks()
ext4_ext_map_blocks()
ext4_ext_try_to_merge_up()
__mark_inode_dirty()
check !I_FREEING
locked_inode_to_wb_and_lock_list()
iput()
iput_final()
evict()
ext4_evict_inode()
truncate_inode_pages_final() //wait release io_end
inode_io_list_move_locked()
ext4_release_io_end()
trigger WARN_ON_ONCE() |
| In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: Fix use-after-free in vidtv_bridge_dvb_init()
KASAN reports a use-after-free:
BUG: KASAN: use-after-free in dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core]
Call Trace:
...
dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core]
vidtv_bridge_probe+0x7bf/0xa40 [dvb_vidtv_bridge]
platform_probe+0xb6/0x170
...
Allocated by task 1238:
...
dvb_register_device+0x1a7/0xa70 [dvb_core]
dvb_dmxdev_init+0x2af/0x4a0 [dvb_core]
vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge]
...
Freed by task 1238:
dvb_register_device+0x6d2/0xa70 [dvb_core]
dvb_dmxdev_init+0x2af/0x4a0 [dvb_core]
vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge]
...
It is because the error handling in vidtv_bridge_dvb_init() is wrong.
First, vidtv_bridge_dmx(dev)_init() will clean themselves when fail, but
goto fail_dmx(_dev): calls release functions again, which causes
use-after-free.
Also, in fail_fe, fail_tuner_probe and fail_demod_probe, j = i will cause
out-of-bound when i finished its loop (i == NUM_FE). And the loop
releasing is wrong, although now NUM_FE is 1 so it won't cause problem.
Fix this by correctly releasing everything. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/chrome: cros_ec_ishtp: Fix UAF after unbinding driver
After unbinding the driver, another kthread `cros_ec_console_log_work`
is still accessing the device, resulting an UAF and crash.
The driver doesn't unregister the EC device in .remove() which should
shutdown sub-devices synchronously. Fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: fix memory leak in bnxt_nvm_test()
Free the kzalloc'ed buffer before returning in the success path. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: qcom: audioreach: fix potential null pointer dereference
It is possible that the topology parsing function
audioreach_widget_load_module_common() could return NULL or an error
pointer. Add missing NULL check so that we do not dereference it. |
| In the Linux kernel, the following vulnerability has been resolved:
media: ipu3-imgu: Fix NULL pointer dereference in active selection access
What the IMGU driver did was that it first acquired the pointers to active
and try V4L2 subdev state, and only then figured out which one to use.
The problem with that approach and a later patch (see Fixes: tag) is that
as sd_state argument to v4l2_subdev_get_try_crop() et al is NULL, there is
now an attempt to dereference that.
Fix this.
Also rewrap lines a little. |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: qcom-adm: fix wrong calling convention for prep_slave_sg
The calling convention for pre_slave_sg is to return NULL on error and
provide an error log to the system. Qcom-adm instead provide error
pointer when an error occur. This indirectly cause kernel panic for
example for the nandc driver that checks only if the pointer returned by
device_prep_slave_sg is not NULL. Returning an error pointer makes nandc
think the device_prep_slave_sg function correctly completed and makes
the kernel panics later in the code.
While nandc is the one that makes the kernel crash, it was pointed out
that the real problem is qcom-adm not following calling convention for
that function.
To fix this, drop returning error pointer and return NULL with an error
log. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ar5523: Fix use-after-free on ar5523_cmd() timed out
syzkaller reported use-after-free with the stack trace like below [1]:
[ 38.960489][ C3] ==================================================================
[ 38.963216][ C3] BUG: KASAN: use-after-free in ar5523_cmd_tx_cb+0x220/0x240
[ 38.964950][ C3] Read of size 8 at addr ffff888048e03450 by task swapper/3/0
[ 38.966363][ C3]
[ 38.967053][ C3] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.0.0-09039-ga6afa4199d3d-dirty #18
[ 38.968464][ C3] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014
[ 38.969959][ C3] Call Trace:
[ 38.970841][ C3] <IRQ>
[ 38.971663][ C3] dump_stack_lvl+0xfc/0x174
[ 38.972620][ C3] print_report.cold+0x2c3/0x752
[ 38.973626][ C3] ? ar5523_cmd_tx_cb+0x220/0x240
[ 38.974644][ C3] kasan_report+0xb1/0x1d0
[ 38.975720][ C3] ? ar5523_cmd_tx_cb+0x220/0x240
[ 38.976831][ C3] ar5523_cmd_tx_cb+0x220/0x240
[ 38.978412][ C3] __usb_hcd_giveback_urb+0x353/0x5b0
[ 38.979755][ C3] usb_hcd_giveback_urb+0x385/0x430
[ 38.981266][ C3] dummy_timer+0x140c/0x34e0
[ 38.982925][ C3] ? notifier_call_chain+0xb5/0x1e0
[ 38.984761][ C3] ? rcu_read_lock_sched_held+0xb/0x60
[ 38.986242][ C3] ? lock_release+0x51c/0x790
[ 38.987323][ C3] ? _raw_read_unlock_irqrestore+0x37/0x70
[ 38.988483][ C3] ? __wake_up_common_lock+0xde/0x130
[ 38.989621][ C3] ? reacquire_held_locks+0x4a0/0x4a0
[ 38.990777][ C3] ? lock_acquire+0x472/0x550
[ 38.991919][ C3] ? rcu_read_lock_sched_held+0xb/0x60
[ 38.993138][ C3] ? lock_acquire+0x472/0x550
[ 38.994890][ C3] ? dummy_urb_enqueue+0x860/0x860
[ 38.996266][ C3] ? do_raw_spin_unlock+0x16f/0x230
[ 38.997670][ C3] ? dummy_urb_enqueue+0x860/0x860
[ 38.999116][ C3] call_timer_fn+0x1a0/0x6a0
[ 39.000668][ C3] ? add_timer_on+0x4a0/0x4a0
[ 39.002137][ C3] ? reacquire_held_locks+0x4a0/0x4a0
[ 39.003809][ C3] ? __next_timer_interrupt+0x226/0x2a0
[ 39.005509][ C3] __run_timers.part.0+0x69a/0xac0
[ 39.007025][ C3] ? dummy_urb_enqueue+0x860/0x860
[ 39.008716][ C3] ? call_timer_fn+0x6a0/0x6a0
[ 39.010254][ C3] ? cpuacct_percpu_seq_show+0x10/0x10
[ 39.011795][ C3] ? kvm_sched_clock_read+0x14/0x40
[ 39.013277][ C3] ? sched_clock_cpu+0x69/0x2b0
[ 39.014724][ C3] run_timer_softirq+0xb6/0x1d0
[ 39.016196][ C3] __do_softirq+0x1d2/0x9be
[ 39.017616][ C3] __irq_exit_rcu+0xeb/0x190
[ 39.019004][ C3] irq_exit_rcu+0x5/0x20
[ 39.020361][ C3] sysvec_apic_timer_interrupt+0x8f/0xb0
[ 39.021965][ C3] </IRQ>
[ 39.023237][ C3] <TASK>
In ar5523_probe(), ar5523_host_available() calls ar5523_cmd() as below
(there are other functions which finally call ar5523_cmd()):
ar5523_probe()
-> ar5523_host_available()
-> ar5523_cmd_read()
-> ar5523_cmd()
If ar5523_cmd() timed out, then ar5523_host_available() failed and
ar5523_probe() freed the device structure. So, ar5523_cmd_tx_cb()
might touch the freed structure.
This patch fixes this issue by canceling in-flight tx cmd if submitted
urb timed out. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921e: fix rmmod crash in driver reload test
In insmod/rmmod stress test, the following crash dump shows up immediately.
The problem is caused by missing mt76_dev in mt7921_pci_remove(). We
should make sure the drvdata is ready before probe() finished.
[168.862789] ==================================================================
[168.862797] BUG: KASAN: user-memory-access in try_to_grab_pending+0x59/0x480
[168.862805] Write of size 8 at addr 0000000000006df0 by task rmmod/5361
[168.862812] CPU: 7 PID: 5361 Comm: rmmod Tainted: G OE 5.19.0-rc6 #1
[168.862816] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, 05/04/2020
[168.862820] Call Trace:
[168.862822] <TASK>
[168.862825] dump_stack_lvl+0x49/0x63
[168.862832] print_report.cold+0x493/0x6b7
[168.862845] kasan_report+0xa7/0x120
[168.862857] kasan_check_range+0x163/0x200
[168.862861] __kasan_check_write+0x14/0x20
[168.862866] try_to_grab_pending+0x59/0x480
[168.862870] __cancel_work_timer+0xbb/0x340
[168.862898] cancel_work_sync+0x10/0x20
[168.862902] mt7921_pci_remove+0x61/0x1c0 [mt7921e]
[168.862909] pci_device_remove+0xa3/0x1d0
[168.862914] device_remove+0xc4/0x170
[168.862920] device_release_driver_internal+0x163/0x300
[168.862925] driver_detach+0xc7/0x1a0
[168.862930] bus_remove_driver+0xeb/0x2d0
[168.862935] driver_unregister+0x71/0xb0
[168.862939] pci_unregister_driver+0x30/0x230
[168.862944] mt7921_pci_driver_exit+0x10/0x1b [mt7921e]
[168.862949] __x64_sys_delete_module+0x2f9/0x4b0
[168.862968] do_syscall_64+0x38/0x90
[168.862973] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Test steps:
1. insmode
2. do not ifup
3. rmmod quickly (within 1 second) |
