Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc-&gt;gadget is NULL<br /> <br /> There exists a possible scenario in which dwc3_gadget_init() can fail:<br /> during during host -&gt; peripheral mode switch in dwc3_set_mode(), and<br /> a pending gadget driver fails to bind. Then, if the DRD undergoes<br /> another mode switch from peripheral-&gt;host the resulting<br /> dwc3_gadget_exit() will attempt to reference an invalid and dangling<br /> dwc-&gt;gadget pointer as well as call dma_free_coherent() on unmapped<br /> DMA pointers.<br /> <br /> The exact scenario can be reproduced as follows:<br /> - Start DWC3 in peripheral mode<br /> - Configure ConfigFS gadget with FunctionFS instance (or use g_ffs)<br /> - Run FunctionFS userspace application (open EPs, write descriptors, etc)<br /> - Bind gadget driver to DWC3&amp;#39;s UDC<br /> - Switch DWC3 to host mode<br /> =&gt; dwc3_gadget_exit() is called. usb_del_gadget() will put the<br /> ConfigFS driver instance on the gadget_driver_pending_list<br /> - Stop FunctionFS application (closes the ep files)<br /> - Switch DWC3 to peripheral mode<br /> =&gt; dwc3_gadget_init() fails as usb_add_gadget() calls<br /> check_pending_gadget_drivers() and attempts to rebind the UDC<br /> to the ConfigFS gadget but fails with -19 (-ENODEV) because the<br /> FFS instance is not in FFS_ACTIVE state (userspace has not<br /> re-opened and written the descriptors yet, i.e. desc_ready!=0).<br /> - Switch DWC3 back to host mode<br /> =&gt; dwc3_gadget_exit() is called again, but this time dwc-&gt;gadget<br /> is invalid.<br /> <br /> Although it can be argued that userspace should take responsibility<br /> for ensuring that the FunctionFS application be ready prior to<br /> allowing the composite driver bind to the UDC, failure to do so<br /> should not result in a panic from the kernel driver.<br /> <br /> Fix this by setting dwc-&gt;gadget to NULL in the failure path of<br /> dwc3_gadget_init() and add a check to dwc3_gadget_exit() to bail out<br /> unless the gadget pointer is valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3-meson-g12a: fix usb2 PHY glue init when phy0 is disabled<br /> <br /> When only PHY1 is used (for example on Odroid-HC4), the regmap init code<br /> uses the usb2 ports when doesn&amp;#39;t initialize the PHY1 regmap entry.<br /> <br /> This fixes:<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> ...<br /> pc : regmap_update_bits_base+0x40/0xa0<br /> lr : dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8<br /> ...<br /> Call trace:<br /> regmap_update_bits_base+0x40/0xa0<br /> dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8<br /> dwc3_meson_g12a_usb2_init+0x7c/0xc8<br /> dwc3_meson_g12a_usb_init+0x28/0x48<br /> dwc3_meson_g12a_probe+0x298/0x540<br /> platform_probe+0x70/0xe0<br /> really_probe+0xf0/0x4d8<br /> driver_probe_device+0xfc/0x168<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Correct the length check which causes memory corruption<br /> <br /> We&amp;#39;ve suffered from severe kernel crashes due to memory corruption on<br /> our production environment, like,<br /> <br /> Call Trace:<br /> [1640542.554277] general protection fault: 0000 [#1] SMP PTI<br /> [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G<br /> [1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190<br /> [1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286<br /> [1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX:<br /> 0000000006e931bf<br /> [1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI:<br /> ffff9a45ff004300<br /> [1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09:<br /> 0000000000000000<br /> [1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12:<br /> ffffffff9a20608d<br /> [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15:<br /> 696c662f65636976<br /> [1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000)<br /> knlGS:0000000000000000<br /> [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4:<br /> 00000000003606e0<br /> [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br /> 0000000000000000<br /> [1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:<br /> 0000000000000400<br /> [1640542.566742] Call Trace:<br /> [1640542.567009] anon_vma_clone+0x5d/0x170<br /> [1640542.567417] __split_vma+0x91/0x1a0<br /> [1640542.567777] do_munmap+0x2c6/0x320<br /> [1640542.568128] vm_munmap+0x54/0x70<br /> [1640542.569990] __x64_sys_munmap+0x22/0x30<br /> [1640542.572005] do_syscall_64+0x5b/0x1b0<br /> [1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> [1640542.575642] RIP: 0033:0x7f45d6e61e27<br /> <br /> James Wang has reproduced it stably on the latest 4.19 LTS.<br /> After some debugging, we finally proved that it&amp;#39;s due to ftrace<br /> buffer out-of-bound access using a debug tool as follows:<br /> [ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000<br /> [ 86.780806] no_context+0xdf/0x3c0<br /> [ 86.784327] __do_page_fault+0x252/0x470<br /> [ 86.788367] do_page_fault+0x32/0x140<br /> [ 86.792145] page_fault+0x1e/0x30<br /> [ 86.795576] strncpy_from_unsafe+0x66/0xb0<br /> [ 86.799789] fetch_memory_string+0x25/0x40<br /> [ 86.804002] fetch_deref_string+0x51/0x60<br /> [ 86.808134] kprobe_trace_func+0x32d/0x3a0<br /> [ 86.812347] kprobe_dispatcher+0x45/0x50<br /> [ 86.816385] kprobe_ftrace_handler+0x90/0xf0<br /> [ 86.820779] ftrace_ops_assist_func+0xa1/0x140<br /> [ 86.825340] 0xffffffffc00750bf<br /> [ 86.828603] do_sys_open+0x5/0x1f0<br /> [ 86.832124] do_syscall_64+0x5b/0x1b0<br /> [ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> commit b220c049d519 ("tracing: Check length before giving out<br /> the filter buffer") adds length check to protect trace data<br /> overflow introduced in 0fc1b09ff1ff, seems that this fix can&amp;#39;t prevent<br /> overflow entirely, the length check should also take the sizeof<br /> entry-&gt;array[0] into account, since this array[0] is filled the<br /> length of trace data and occupy addtional space and risk overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcache: avoid oversized read request in cache missing code path<br /> <br /> In the cache missing code path of cached device, if a proper location<br /> from the internal B+ tree is matched for a cache miss range, function<br /> cached_dev_cache_miss() will be called in cache_lookup_fn() in the<br /> following code block,<br /> [code block 1]<br /> 526 unsigned int sectors = KEY_INODE(k) == s-&gt;iop.inode<br /> 527 ? min_t(uint64_t, INT_MAX,<br /> 528 KEY_START(k) - bio-&gt;bi_iter.bi_sector)<br /> 529 : INT_MAX;<br /> 530 int ret = s-&gt;d-&gt;cache_miss(b, s, bio, sectors);<br /> <br /> Here s-&gt;d-&gt;cache_miss() is the call backfunction pointer initialized as<br /> cached_dev_cache_miss(), the last parameter &amp;#39;sectors&amp;#39; is an important<br /> hint to calculate the size of read request to backing device of the<br /> missing cache data.<br /> <br /> Current calculation in above code block may generate oversized value of<br /> &amp;#39;sectors&amp;#39;, which consequently may trigger 2 different potential kernel<br /> panics by BUG() or BUG_ON() as listed below,<br /> <br /> 1) BUG_ON() inside bch_btree_insert_key(),<br /> [code block 2]<br /> 886 BUG_ON(b-&gt;ops-&gt;is_extents &amp;&amp; !KEY_SIZE(k));<br /> 2) BUG() inside biovec_slab(),<br /> [code block 3]<br /> 51 default:<br /> 52 BUG();<br /> 53 return NULL;<br /> <br /> All the above panics are original from cached_dev_cache_miss() by the<br /> oversized parameter &amp;#39;sectors&amp;#39;.<br /> <br /> Inside cached_dev_cache_miss(), parameter &amp;#39;sectors&amp;#39; is used to calculate<br /> the size of data read from backing device for the cache missing. This<br /> size is stored in s-&gt;insert_bio_sectors by the following lines of code,<br /> [code block 4]<br /> 909 s-&gt;insert_bio_sectors = min(sectors, bio_sectors(bio) + reada);<br /> <br /> Then the actual key inserting to the internal B+ tree is generated and<br /> stored in s-&gt;iop.replace_key by the following lines of code,<br /> [code block 5]<br /> 911 s-&gt;iop.replace_key = KEY(s-&gt;iop.inode,<br /> 912 bio-&gt;bi_iter.bi_sector + s-&gt;insert_bio_sectors,<br /> 913 s-&gt;insert_bio_sectors);<br /> The oversized parameter &amp;#39;sectors&amp;#39; may trigger panic 1) by BUG_ON() from<br /> the above code block.<br /> <br /> And the bio sending to backing device for the missing data is allocated<br /> with hint from s-&gt;insert_bio_sectors by the following lines of code,<br /> [code block 6]<br /> 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT,<br /> 927 DIV_ROUND_UP(s-&gt;insert_bio_sectors, PAGE_SECTORS),<br /> 928 &amp;dc-&gt;disk.bio_split);<br /> The oversized parameter &amp;#39;sectors&amp;#39; may trigger panic 2) by BUG() from the<br /> agove code block.<br /> <br /> Now let me explain how the panics happen with the oversized &amp;#39;sectors&amp;#39;.<br /> In code block 5, replace_key is generated by macro KEY(). From the<br /> definition of macro KEY(),<br /> [code block 7]<br /> 71 #define KEY(inode, offset, size) \<br /> 72 ((struct bkey) { \<br /> 73 .high = (1ULL

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Do not blindly read the ip address in ftrace_bug()<br /> <br /> It was reported that a bug on arm64 caused a bad ip address to be used for<br /> updating into a nop in ftrace_init(), but the error path (rightfully)<br /> returned -EINVAL and not -EFAULT, as the bug caused more than one error to<br /> occur. But because -EINVAL was returned, the ftrace_bug() tried to report<br /> what was at the location of the ip address, and read it directly. This<br /> caused the machine to panic, as the ip was not pointing to a valid memory<br /> address.<br /> <br /> Instead, read the ip address with copy_from_kernel_nofault() to safely<br /> access the memory, and if it faults, report that the address faulted,<br /> otherwise report what was in that location.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: fix skb length check in ieee80211_scan_rx()<br /> <br /> Replace hard-coded compile-time constants for header length check<br /> with dynamic determination based on the frame type. Otherwise, we<br /> hit a validation WARN_ON in cfg80211 later.<br /> <br /> [style fixes, reword commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: Avoid WARN_ON timing related checks<br /> <br /> The soft/batadv interface for a queued OGM can be changed during the time<br /> the OGM was queued for transmission and when the OGM is actually<br /> transmitted by the worker.<br /> <br /> But WARN_ON must be used to denote kernel bugs and not to print simple<br /> warnings. A warning can simply be printed using pr_warn.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix potential memory leak in DMUB hw_init<br /> <br /> [Why]<br /> On resume we perform DMUB hw_init which allocates memory:<br /> dm_resume-&gt;dm_dmub_hw_init-&gt;dc_dmub_srv_create-&gt;kzalloc<br /> That results in memory leak in suspend/resume scenarios.<br /> <br /> [How]<br /> Allocate memory for the DC wrapper to DMUB only if it was not<br /> allocated before.<br /> No need to reallocate it on suspend/resume.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kvm: LAPIC: Restore guard to prevent illegal APIC register access<br /> <br /> Per the SDM, "any access that touches bytes 4 through 15 of an APIC<br /> register may cause undefined behavior and must not be executed."<br /> Worse, such an access in kvm_lapic_reg_read can result in a leak of<br /> kernel stack contents. Prior to commit 01402cf81051 ("kvm: LAPIC:<br /> write down valid APIC registers"), such an access was explicitly<br /> disallowed. Restore the guard that was removed in that commit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/memory-failure: make sure wait for page writeback in memory_failure<br /> <br /> Our syzkaller trigger the "BUG_ON(!list_empty(&amp;inode-&gt;i_wb_list))" in<br /> clear_inode:<br /> <br /> kernel BUG at fs/inode.c:519!<br /> Internal error: Oops - BUG: 0 [#1] SMP<br /> Modules linked in:<br /> Process syz-executor.0 (pid: 249, stack limit = 0x00000000a12409d7)<br /> CPU: 1 PID: 249 Comm: syz-executor.0 Not tainted 4.19.95<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 80000005 (Nzcv daif -PAN -UAO)<br /> pc : clear_inode+0x280/0x2a8<br /> lr : clear_inode+0x280/0x2a8<br /> Call trace:<br /> clear_inode+0x280/0x2a8<br /> ext4_clear_inode+0x38/0xe8<br /> ext4_free_inode+0x130/0xc68<br /> ext4_evict_inode+0xb20/0xcb8<br /> evict+0x1a8/0x3c0<br /> iput+0x344/0x460<br /> do_unlinkat+0x260/0x410<br /> __arm64_sys_unlinkat+0x6c/0xc0<br /> el0_svc_common+0xdc/0x3b0<br /> el0_svc_handler+0xf8/0x160<br /> el0_svc+0x10/0x218<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> A crash dump of this problem show that someone called __munlock_pagevec<br /> to clear page LRU without lock_page: do_mmap -&gt; mmap_region -&gt; do_munmap<br /> -&gt; munlock_vma_pages_range -&gt; __munlock_pagevec.<br /> <br /> As a result memory_failure will call identify_page_state without<br /> wait_on_page_writeback. And after truncate_error_page clear the mapping<br /> of this page. end_page_writeback won&amp;#39;t call sb_clear_inode_writeback to<br /> clear inode-&gt;i_wb_list. That will trigger BUG_ON in clear_inode!<br /> <br /> Fix it by checking PageWriteback too to help determine should we skip<br /> wait_on_page_writeback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ieee802154: fix null deref in parse dev addr<br /> <br /> Fix a logic error that could result in a null deref if the user sets<br /> the mode incorrectly for the given addr type.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Fix error handling of scsi_host_alloc()<br /> <br /> After device is initialized via device_initialize(), or its name is set via<br /> dev_set_name(), the device has to be freed via put_device(). Otherwise<br /> device name will be leaked because it is allocated dynamically in<br /> dev_set_name().<br /> <br /> Fix the leak by replacing kfree() with put_device(). Since<br /> scsi_host_dev_release() properly handles IDA and kthread removal, remove<br /> special-casing these from the error handling as well.