Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mce: Work around an erratum on fast string copy instructions<br /> <br /> A rare kernel panic scenario can happen when the following conditions<br /> are met due to an erratum on fast string copy instructions:<br /> <br /> 1) An uncorrected error.<br /> 2) That error must be in first cache line of a page.<br /> 3) Kernel must execute page_copy from the page immediately before that<br /> page.<br /> <br /> The fast string copy instructions ("REP; MOVS*") could consume an<br /> uncorrectable memory error in the cache line _right after_ the desired<br /> region to copy and raise an MCE.<br /> <br /> Bit 0 of MSR_IA32_MISC_ENABLE can be cleared to disable fast string<br /> copy and will avoid such spurious machine checks. However, that is less<br /> preferable due to the permanent performance impact. Considering memory<br /> poison is rare, it&amp;#39;s desirable to keep fast string copy enabled until an<br /> MCE is seen.<br /> <br /> Intel has confirmed the following:<br /> 1. The CPU erratum of fast string copy only applies to Skylake,<br /> Cascade Lake and Cooper Lake generations.<br /> <br /> Directly return from the MCE handler:<br /> 2. Will result in complete execution of the "REP; MOVS*" with no data<br /> loss or corruption.<br /> 3. Will not result in another MCE firing on the next poisoned cache line<br /> due to "REP; MOVS*".<br /> 4. Will resume execution from a correct point in code.<br /> 5. Will result in the same instruction that triggered the MCE firing a<br /> second MCE immediately for any other software recoverable data fetch<br /> errors.<br /> 6. Is not safe without disabling the fast string copy, as the next fast<br /> string copy of the same buffer on the same CPU would result in a PANIC<br /> MCE.<br /> <br /> This should mitigate the erratum completely with the only caveat that<br /> the fast string copy is disabled on the affected hyper thread thus<br /> performance degradation.<br /> <br /> This is still better than the OS crashing on MCEs raised on an<br /> irrelevant process due to "REP; MOVS*&amp;#39; accesses in a kernel context,<br /> e.g., copy_page.<br /> <br /> <br /> Injected errors on 1st cache line of 8 anonymous pages of process<br /> &amp;#39;proc1&amp;#39; and observed MCE consumption from &amp;#39;proc2&amp;#39; with no panic<br /> (directly returned).<br /> <br /> Without the fix, the host panicked within a few minutes on a<br /> random &amp;#39;proc2&amp;#39; process due to kernel access from copy_page.<br /> <br /> [ bp: Fix comment style + touch ups, zap an unlikely(), improve the<br /> quirk function&amp;#39;s readability. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sprd: fix potential NULL dereference<br /> <br /> &amp;#39;drm&amp;#39; could be null in sprd_drm_shutdown, and drm_warn maybe dereference<br /> it, remove this warning log.<br /> <br /> <br /> v1 -&gt; v2:<br /> - Split checking platform_get_resource() return value to a separate patch<br /> - Use dev_warn() instead of removing the warning log

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix memory leaks<br /> <br /> Fix memory leaks related to operational reply queue&amp;#39;s memory segments which<br /> are not getting freed while unloading the driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mips: ralink: fix a refcount leak in ill_acc_of_setup()<br /> <br /> of_node_put(np) needs to be called when pdev == NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: vchiq_arm: Avoid NULL ptr deref in vchiq_dump_platform_instances<br /> <br /> vchiq_get_state() can return a NULL pointer. So handle this cases and<br /> avoid a NULL pointer derefence in vchiq_dump_platform_instances.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix memory leak in ceph_readdir when note_last_dentry returns error<br /> <br /> Reset the last_readdir at the same time, and add a comment explaining<br /> why we don&amp;#39;t free last_readdir when dir_emit returns false.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: Fix memory leaks on probe<br /> <br /> Handle the error branches to free memory where required.<br /> <br /> Addresses-Coverity-ID: 1491825 ("Resource leak")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix inode reference leakage in ceph_get_snapdir()<br /> <br /> The ceph_get_inode() will search for or insert a new inode into the<br /> hash for the given vino, and return a reference to it. If new is<br /> non-NULL, its reference is consumed.<br /> <br /> We should release the reference when in error handing cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: revisit gc autotuning<br /> <br /> as of commit 4608fdfc07e1<br /> ("netfilter: conntrack: collect all entries in one cycle")<br /> conntrack gc was changed to run every 2 minutes.<br /> <br /> On systems where conntrack hash table is set to large value, most evictions<br /> happen from gc worker rather than the packet path due to hash table<br /> distribution.<br /> <br /> This causes netlink event overflows when events are collected.<br /> <br /> This change collects average expiry of scanned entries and<br /> reschedules to the average remaining value, within 1 to 60 second interval.<br /> <br /> To avoid event overflows, reschedule after each bucket and add a<br /> limit for both run time and number of evictions per run.<br /> <br /> If more entries have to be evicted, reschedule and restart 1 jiffy<br /> into the future.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix use after free in hci_send_acl<br /> <br /> This fixes the following trace caused by receiving<br /> HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without<br /> first checking if conn-&gt;type is in fact AMP_LINK and in case it is<br /> do properly cleanup upper layers with hci_disconn_cfm:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50<br /> Read of size 8 at addr ffff88800e404818 by task bluetoothd/142<br /> <br /> CPU: 0 PID: 142 Comm: bluetoothd Not tainted<br /> 5.17.0-rc5-00006-gda4022eeac1a #7<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x45/0x59<br /> print_address_description.constprop.0+0x1f/0x150<br /> kasan_report.cold+0x7f/0x11b<br /> hci_send_acl+0xaba/0xc50<br /> l2cap_do_send+0x23f/0x3d0<br /> l2cap_chan_send+0xc06/0x2cc0<br /> l2cap_sock_sendmsg+0x201/0x2b0<br /> sock_sendmsg+0xdc/0x110<br /> sock_write_iter+0x20f/0x370<br /> do_iter_readv_writev+0x343/0x690<br /> do_iter_write+0x132/0x640<br /> vfs_writev+0x198/0x570<br /> do_writev+0x202/0x280<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014<br /> Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3<br /> 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05<br /> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10<br /> RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015<br /> RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77<br /> R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580<br /> RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001<br /> <br /> R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0<br /> <br /> Allocated by task 45:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_kmalloc+0x81/0xa0<br /> hci_chan_create+0x9a/0x2f0<br /> l2cap_conn_add.part.0+0x1a/0xdc0<br /> l2cap_connect_cfm+0x236/0x1000<br /> le_conn_complete_evt+0x15a7/0x1db0<br /> hci_le_conn_complete_evt+0x226/0x2c0<br /> hci_le_meta_evt+0x247/0x450<br /> hci_event_packet+0x61b/0xe90<br /> hci_rx_work+0x4d5/0xc50<br /> process_one_work+0x8fb/0x15a0<br /> worker_thread+0x576/0x1240<br /> kthread+0x29d/0x340<br /> ret_from_fork+0x1f/0x30<br /> <br /> Freed by task 45:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> kasan_set_free_info+0x20/0x30<br /> __kasan_slab_free+0xfb/0x130<br /> kfree+0xac/0x350<br /> hci_conn_cleanup+0x101/0x6a0<br /> hci_conn_del+0x27e/0x6c0<br /> hci_disconn_phylink_complete_evt+0xe0/0x120<br /> hci_event_packet+0x812/0xe90<br /> hci_rx_work+0x4d5/0xc50<br /> process_one_work+0x8fb/0x15a0<br /> worker_thread+0x576/0x1240<br /> kthread+0x29d/0x340<br /> ret_from_fork+0x1f/0x30<br /> <br /> The buggy address belongs to the object at ffff88800c0f0500<br /> The buggy address is located 24 bytes inside of<br /> which belongs to the cache kmalloc-128 of size 128<br /> The buggy address belongs to the page:<br /> 128-byte region [ffff88800c0f0500, ffff88800c0f0580)<br /> flags: 0x100000000000200(slab|node=0|zone=1)<br /> page:00000000fe45cd86 refcount:1 mapcount:0<br /> mapping:0000000000000000 index:0x0 pfn:0xc0f0<br /> raw: 0000000000000000 0000000080100010 00000001ffffffff<br /> 0000000000000000<br /> raw: 0100000000000200 ffffea00003a2c80 dead000000000004<br /> ffff8880078418c0<br /> page dumped because: kasan: bad access detected<br /> ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc<br /> Memory state around the buggy address:<br /> &gt;ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: fix monitor mode crash with sdio driver<br /> <br /> mt7921s driver may receive frames with fragment buffers. If there is a<br /> CTS packet received in monitor mode, the payload is 10 bytes only and<br /> need 6 bytes header padding after RXD buffer. However, only RXD in the<br /> first linear buffer, if we pull buffer size RXD-size+6 bytes with<br /> skb_pull(), that would trigger "BUG_ON(skb-&gt;len data_len)" in<br /> __skb_pull().<br /> <br /> To avoid the nonlinear buffer issue, enlarge the RXD size from 128 to<br /> 256 to make sure all MCU operation in linear buffer.<br /> <br /> [ 52.007562] kernel BUG at include/linux/skbuff.h:2313!<br /> [ 52.007578] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> [ 52.007987] pc : skb_pull+0x48/0x4c<br /> [ 52.008015] lr : mt7921_queue_rx_skb+0x494/0x890 [mt7921_common]<br /> [ 52.008361] Call trace:<br /> [ 52.008377] skb_pull+0x48/0x4c<br /> [ 52.008400] mt76s_net_worker+0x134/0x1b0 [mt76_sdio 35339a92c6eb7d4bbcc806a1d22f56365565135c]<br /> [ 52.008431] __mt76_worker_fn+0xe8/0x170 [mt76 ef716597d11a77150bc07e3fdd68eeb0f9b56917]<br /> [ 52.008449] kthread+0x148/0x3ac<br /> [ 52.008466] ret_from_fork+0x10/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/secvar: fix refcount leak in format_show()<br /> <br /> Refcount leak will happen when format_show returns failure in multiple<br /> cases. Unified management of of_node_put can fix this problem.