Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Add oversize check before call kvcalloc()<br /> <br /> Commit 7661809d493b ("mm: don&amp;#39;t allow oversized kvmalloc() calls") add the<br /> oversize check. When the allocation is larger than what kmalloc() supports,<br /> the following warning triggered:<br /> <br /> WARNING: CPU: 0 PID: 8408 at mm/util.c:597 kvmalloc_node+0x108/0x110 mm/util.c:597<br /> Modules linked in:<br /> CPU: 0 PID: 8408 Comm: syz-executor221 Not tainted 5.14.0-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:kvmalloc_node+0x108/0x110 mm/util.c:597<br /> Call Trace:<br /> kvmalloc include/linux/mm.h:806 [inline]<br /> kvmalloc_array include/linux/mm.h:824 [inline]<br /> kvcalloc include/linux/mm.h:829 [inline]<br /> check_btf_line kernel/bpf/verifier.c:9925 [inline]<br /> check_btf_info kernel/bpf/verifier.c:10049 [inline]<br /> bpf_check+0xd634/0x150d0 kernel/bpf/verifier.c:13759<br /> bpf_prog_load kernel/bpf/syscall.c:2301 [inline]<br /> __sys_bpf+0x11181/0x126e0 kernel/bpf/syscall.c:4587<br /> __do_sys_bpf kernel/bpf/syscall.c:4691 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:4689 [inline]<br /> __x64_sys_bpf+0x78/0x90 kernel/bpf/syscall.c:4689<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-rdma: destroy cm id before destroy qp to avoid use after free<br /> <br /> We should always destroy cm_id before destroy qp to avoid to get cma<br /> event after qp was destroyed, which may lead to use after free.<br /> In RDMA connection establishment error flow, don&amp;#39;t destroy qp in cm<br /> event handler.Just report cm_error to upper level, qp will be destroy<br /> in nvme_rdma_alloc_queue() after destroy cm id.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: fix UAF by grabbing blkcg lock before destroying blkg pd<br /> <br /> KASAN reports a use-after-free report when doing fuzz test:<br /> <br /> [693354.104835] ==================================================================<br /> [693354.105094] BUG: KASAN: use-after-free in bfq_io_set_weight_legacy+0xd3/0x160<br /> [693354.105336] Read of size 4 at addr ffff888be0a35664 by task sh/1453338<br /> <br /> [693354.105607] CPU: 41 PID: 1453338 Comm: sh Kdump: loaded Not tainted 4.18.0-147<br /> [693354.105610] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 0.81 07/02/2018<br /> [693354.105612] Call Trace:<br /> [693354.105621] dump_stack+0xf1/0x19b<br /> [693354.105626] ? show_regs_print_info+0x5/0x5<br /> [693354.105634] ? printk+0x9c/0xc3<br /> [693354.105638] ? cpumask_weight+0x1f/0x1f<br /> [693354.105648] print_address_description+0x70/0x360<br /> [693354.105654] kasan_report+0x1b2/0x330<br /> [693354.105659] ? bfq_io_set_weight_legacy+0xd3/0x160<br /> [693354.105665] ? bfq_io_set_weight_legacy+0xd3/0x160<br /> [693354.105670] bfq_io_set_weight_legacy+0xd3/0x160<br /> [693354.105675] ? bfq_cpd_init+0x20/0x20<br /> [693354.105683] cgroup_file_write+0x3aa/0x510<br /> [693354.105693] ? ___slab_alloc+0x507/0x540<br /> [693354.105698] ? cgroup_file_poll+0x60/0x60<br /> [693354.105702] ? 0xffffffff89600000<br /> [693354.105708] ? usercopy_abort+0x90/0x90<br /> [693354.105716] ? mutex_lock+0xef/0x180<br /> [693354.105726] kernfs_fop_write+0x1ab/0x280<br /> [693354.105732] ? cgroup_file_poll+0x60/0x60<br /> [693354.105738] vfs_write+0xe7/0x230<br /> [693354.105744] ksys_write+0xb0/0x140<br /> [693354.105749] ? __ia32_sys_read+0x50/0x50<br /> [693354.105760] do_syscall_64+0x112/0x370<br /> [693354.105766] ? syscall_return_slowpath+0x260/0x260<br /> [693354.105772] ? do_page_fault+0x9b/0x270<br /> [693354.105779] ? prepare_exit_to_usermode+0xf9/0x1a0<br /> [693354.105784] ? enter_from_user_mode+0x30/0x30<br /> [693354.105793] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> <br /> [693354.105875] Allocated by task 1453337:<br /> [693354.106001] kasan_kmalloc+0xa0/0xd0<br /> [693354.106006] kmem_cache_alloc_node_trace+0x108/0x220<br /> [693354.106010] bfq_pd_alloc+0x96/0x120<br /> [693354.106015] blkcg_activate_policy+0x1b7/0x2b0<br /> [693354.106020] bfq_create_group_hierarchy+0x1e/0x80<br /> [693354.106026] bfq_init_queue+0x678/0x8c0<br /> [693354.106031] blk_mq_init_sched+0x1f8/0x460<br /> [693354.106037] elevator_switch_mq+0xe1/0x240<br /> [693354.106041] elevator_switch+0x25/0x40<br /> [693354.106045] elv_iosched_store+0x1a1/0x230<br /> [693354.106049] queue_attr_store+0x78/0xb0<br /> [693354.106053] kernfs_fop_write+0x1ab/0x280<br /> [693354.106056] vfs_write+0xe7/0x230<br /> [693354.106060] ksys_write+0xb0/0x140<br /> [693354.106064] do_syscall_64+0x112/0x370<br /> [693354.106069] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> <br /> [693354.106114] Freed by task 1453336:<br /> [693354.106225] __kasan_slab_free+0x130/0x180<br /> [693354.106229] kfree+0x90/0x1b0<br /> [693354.106233] blkcg_deactivate_policy+0x12c/0x220<br /> [693354.106238] bfq_exit_queue+0xf5/0x110<br /> [693354.106241] blk_mq_exit_sched+0x104/0x130<br /> [693354.106245] __elevator_exit+0x45/0x60<br /> [693354.106249] elevator_switch_mq+0xd6/0x240<br /> [693354.106253] elevator_switch+0x25/0x40<br /> [693354.106257] elv_iosched_store+0x1a1/0x230<br /> [693354.106261] queue_attr_store+0x78/0xb0<br /> [693354.106264] kernfs_fop_write+0x1ab/0x280<br /> [693354.106268] vfs_write+0xe7/0x230<br /> [693354.106271] ksys_write+0xb0/0x140<br /> [693354.106275] do_syscall_64+0x112/0x370<br /> [693354.106280] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> <br /> [693354.106329] The buggy address belongs to the object at ffff888be0a35580<br /> which belongs to the cache kmalloc-1k of size 1024<br /> [693354.106736] The buggy address is located 228 bytes inside of<br /> 1024-byte region [ffff888be0a35580, ffff888be0a35980)<br /> [693354.107114] The buggy address belongs to the page:<br /> [693354.107273] page:ffffea002f828c00 count:1 mapcount:0 mapping:ffff888107c17080 index:0x0 compound_mapcount: 0<br /> [693354.107606] flags: 0x17ffffc0008100(slab|head)<br /> [693354.107760] raw: 0017ffffc0008100 ffffea002fcbc808 ffffea0030bd3a08 ffff888107c17080<br /> [693354.108020] r<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: amd_sfh: Fix potential NULL pointer dereference<br /> <br /> devm_add_action_or_reset() can suddenly invoke amd_mp2_pci_remove() at<br /> registration that will cause NULL pointer dereference since<br /> corresponding data is not initialized yet. The patch moves<br /> initialization of data before devm_add_action_or_reset().<br /> <br /> Found by Linux Driver Verification project (linuxtesting.org).<br /> <br /> [jkosina@suse.cz: rebase]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: Fix DSP oops stack dump output contents<br /> <br /> Fix @buf arg given to hex_dump_to_buffer() and stack address used<br /> in dump error output.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/qeth: fix deadlock during failing recovery<br /> <br /> Commit 0b9902c1fcc5 ("s390/qeth: fix deadlock during recovery") removed<br /> taking discipline_mutex inside qeth_do_reset(), fixing potential<br /> deadlocks. An error path was missed though, that still takes<br /> discipline_mutex and thus has the original deadlock potential.<br /> <br /> Intermittent deadlocks were seen when a qeth channel path is configured<br /> offline, causing a race between qeth_do_reset and ccwgroup_remove.<br /> Call qeth_set_offline() directly in the qeth_do_reset() error case and<br /> then a new variant of ccwgroup_set_offline(), without taking<br /> discipline_mutex.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field<br /> <br /> If driver read tmp value sufficient for<br /> (tmp &amp; 0x08) &amp;&amp; (!(tmp &amp; 0x80)) &amp;&amp; ((tmp &amp; 0x7) == ((tmp &gt;&gt; 4) &amp; 0x7))<br /> from device then Null pointer dereference occurs.<br /> (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers)<br /> Also lm75[] does not serve a purpose anymore after switching to<br /> devm_i2c_new_dummy_device() in w83791d_detect_subclients().<br /> <br /> The patch fixes possible NULL pointer dereference by removing lm75[].<br /> <br /> Found by Linux Driver Verification project (linuxtesting.org).<br /> <br /> [groeck: Dropped unnecessary continuation lines, fixed multi-line alignments]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: Fix out-of-bound vmalloc access in imageblit<br /> <br /> This issue happens when a userspace program does an ioctl<br /> FBIOPUT_VSCREENINFO passing the fb_var_screeninfo struct<br /> containing only the fields xres, yres, and bits_per_pixel<br /> with values.<br /> <br /> If this struct is the same as the previous ioctl, the<br /> vc_resize() detects it and doesn&amp;#39;t call the resize_screen(),<br /> leaving the fb_var_screeninfo incomplete. And this leads to<br /> the updatescrollmode() calculates a wrong value to<br /> fbcon_display-&gt;vrows, which makes the real_y() return a<br /> wrong value of y, and that value, eventually, causes<br /> the imageblit to access an out-of-bound address value.<br /> <br /> To solve this issue I made the resize_screen() be called<br /> even if the screen does not need any resizing, so it will<br /> "fix and fill" the fb_var_screeninfo independently.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: iphase: fix possible use-after-free in ia_module_exit()<br /> <br /> This module&amp;#39;s remove path calls del_timer(). However, that function<br /> does not wait until the timer handler finishes. This means that the<br /> timer handler may still be running after the driver&amp;#39;s remove function<br /> has finished, which would result in a use-after-free.<br /> <br /> Fix by calling del_timer_sync(), which makes sure the timer handler<br /> has finished, and unable to re-schedule itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: greybus: uart: fix tty use after free<br /> <br /> User space can hold a tty open indefinitely and tty drivers must not<br /> release the underlying structures until the last user is gone.<br /> <br /> Switch to using the tty-port reference counter to manage the life time<br /> of the greybus tty state to avoid use after free after a disconnect.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix soft lockup during fsstress<br /> <br /> Below traces are observed during fsstress and system got hung.<br /> [ 130.698396] watchdog: BUG: soft lockup - CPU#6 stuck for 26s!