Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kvm: avoid speculation-based attacks from out-of-range memslot accesses<br /> <br /> KVM&amp;#39;s mechanism for accessing guest memory translates a guest physical<br /> address (gpa) to a host virtual address using the right-shifted gpa<br /> (also known as gfn) and a struct kvm_memory_slot. The translation is<br /> performed in __gfn_to_hva_memslot using the following formula:<br /> <br /> hva = slot-&gt;userspace_addr + (gfn - slot-&gt;base_gfn) * PAGE_SIZE<br /> <br /> It is expected that gfn falls within the boundaries of the guest&amp;#39;s<br /> physical memory. However, a guest can access invalid physical addresses<br /> in such a way that the gfn is invalid.<br /> <br /> __gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first<br /> retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot<br /> does check that the gfn falls within the boundaries of the guest&amp;#39;s<br /> physical memory or not, a CPU can speculate the result of the check and<br /> continue execution speculatively using an illegal gfn. The speculation<br /> can result in calculating an out-of-bounds hva. If the resulting host<br /> virtual address is used to load another guest physical address, this<br /> is effectively a Spectre gadget consisting of two consecutive reads,<br /> the second of which is data dependent on the first.<br /> <br /> Right now it&amp;#39;s not clear if there are any cases in which this is<br /> exploitable. One interesting case was reported by the original author<br /> of this patch, and involves visiting guest page tables on x86. Right<br /> now these are not vulnerable because the hva read goes through get_user(),<br /> which contains an LFENCE speculation barrier. However, there are<br /> patches in progress for x86 uaccess.h to mask kernel addresses instead of<br /> using LFENCE; once these land, a guest could use speculation to read<br /> from the VMM&amp;#39;s ring 3 address space. Other architectures such as ARM<br /> already use the address masking method, and would be susceptible to<br /> this same kind of data-dependent access gadgets. Therefore, this patch<br /> proactively protects from these attacks by masking out-of-bounds gfns<br /> in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.<br /> <br /> Sean Christopherson noted that this patch does not cover<br /> kvm_read_guest_offset_cached. This however is limited to a few bytes<br /> past the end of the cache, and therefore it is unlikely to be useful in<br /> the context of building a chain of data dependent accesses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: pci_generic: Fix possible use-after-free in mhi_pci_remove()<br /> <br /> This driver&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 /> usb: misc: brcmstb-usb-pinmap: check return value after calling platform_get_resource()<br /> <br /> It will cause null-ptr-deref if platform_get_resource() returns NULL,<br /> we need check the return value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Fix use-after-free read in drm_getunique()<br /> <br /> There is a time-of-check-to-time-of-use error in drm_getunique() due<br /> to retrieving file_priv-&gt;master prior to locking the device&amp;#39;s master<br /> mutex.<br /> <br /> An example can be seen in the crash report of the use-after-free error<br /> found by Syzbot:<br /> https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803<br /> <br /> In the report, the master pointer was used after being freed. This is<br /> because another process had acquired the device&amp;#39;s master mutex in<br /> drm_setmaster_ioctl(), then overwrote fpriv-&gt;master in<br /> drm_new_set_master(). The old value of fpriv-&gt;master was subsequently<br /> freed before the mutex was unlocked.<br /> <br /> To fix this, we lock the device&amp;#39;s master mutex before retrieving the<br /> pointer from from fpriv-&gt;master. This patch passes the Syzbot<br /> reproducer test.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: seq: Fix race of snd_seq_timer_open()<br /> <br /> The timer instance per queue is exclusive, and snd_seq_timer_open()<br /> should have managed the concurrent accesses. It looks as if it&amp;#39;s<br /> checking the already existing timer instance at the beginning, but<br /> it&amp;#39;s not right, because there is no protection, hence any later<br /> concurrent call of snd_seq_timer_open() may override the timer<br /> instance easily. This may result in UAF, as the leftover timer<br /> instance can keep running while the queue itself gets closed, as<br /> spotted by syzkaller recently.<br /> <br /> For avoiding the race, add a proper check at the assignment of<br /> tmr-&gt;timeri again, and return -EBUSY if it&amp;#39;s been already registered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: bcm2835: Fix out-of-bounds access with more than 4 slaves<br /> <br /> Commit 571e31fa60b3 ("spi: bcm2835: Cache CS register value for<br /> -&gt;prepare_message()") limited the number of slaves to 3 at compile-time.<br /> The limitation was necessitated by a statically-sized array prepare_cs[]<br /> in the driver private data which contains a per-slave register value.<br /> <br /> The commit sought to enforce the limitation at run-time by setting the<br /> controller&amp;#39;s num_chipselect to 3: Slaves with a higher chipselect are<br /> rejected by spi_add_device().<br /> <br /> However the commit neglected that num_chipselect only limits the number<br /> of *native* chipselects. If GPIO chipselects are specified in the<br /> device tree for more than 3 slaves, num_chipselect is silently raised by<br /> of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to<br /> the statically-sized array prepare_cs[].<br /> <br /> As a bandaid fix which is backportable to stable, raise the number of<br /> allowed slaves to 24 (which "ought to be enough for anybody"), enforce<br /> the limitation on slave -&gt;setup and revert num_chipselect to 3 (which is<br /> the number of native chipselects supported by the controller).<br /> An upcoming for-next commit will allow an arbitrary number of slaves.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net:sfc: fix non-freed irq in legacy irq mode<br /> <br /> SFC driver can be configured via modparam to work using MSI-X, MSI or<br /> legacy IRQ interrupts. In the last one, the interrupt was not properly<br /> released on module remove.<br /> <br /> It was not freed because the flag irqs_hooked was not set during<br /> initialization in the case of using legacy IRQ.<br /> <br /> Example of (trimmed) trace during module remove without this fix:<br /> <br /> remove_proc_entry: removing non-empty directory &amp;#39;irq/125&amp;#39;, leaking at least &amp;#39;0000:3b:00.1&amp;#39;<br /> WARNING: CPU: 39 PID: 3658 at fs/proc/generic.c:715 remove_proc_entry+0x15c/0x170<br /> ...trimmed...<br /> Call Trace:<br /> unregister_irq_proc+0xe3/0x100<br /> free_desc+0x29/0x70<br /> irq_free_descs+0x47/0x70<br /> mp_unmap_irq+0x58/0x60<br /> acpi_unregister_gsi_ioapic+0x2a/0x40<br /> acpi_pci_irq_disable+0x78/0xb0<br /> pci_disable_device+0xd1/0x100<br /> efx_pci_remove+0xa1/0x1e0 [sfc]<br /> pci_device_remove+0x38/0xa0<br /> __device_release_driver+0x177/0x230<br /> driver_detach+0xcb/0x110<br /> bus_remove_driver+0x58/0xd0<br /> pci_unregister_driver+0x2a/0xb0<br /> efx_exit_module+0x24/0xf40 [sfc]<br /> __do_sys_delete_module.constprop.0+0x171/0x280<br /> ? exit_to_user_mode_prepare+0x83/0x1d0<br /> do_syscall_64+0x3d/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f9f9385800b<br /> ...trimmed...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> isdn: mISDN: netjet: Fix crash in nj_probe:<br /> <br /> &amp;#39;nj_setup&amp;#39; in netjet.c might fail with -EIO and in this case<br /> &amp;#39;card-&gt;irq&amp;#39; is initialized and is bigger than zero. A subsequent call to<br /> &amp;#39;nj_release&amp;#39; will free the irq that has not been requested.<br /> <br /> Fix this bug by deleting the previous assignment to &amp;#39;card-&gt;irq&amp;#39; and just<br /> keep the assignment before &amp;#39;request_irq&amp;#39;.<br /> <br /> The KASAN&amp;#39;s log reveals it:<br /> <br /> [ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826<br /> free_irq+0x100/0x480<br /> [ 3.355112 ] Modules linked in:<br /> [ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted<br /> 5.13.0-rc1-00144-g25a1298726e #13<br /> [ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS<br /> rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014<br /> [ 3.356552 ] RIP: 0010:free_irq+0x100/0x480<br /> [ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18<br /> 4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5<br /> ff 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80<br /> [ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082<br /> [ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX:<br /> 0000000000000000<br /> [ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI:<br /> 00000000ffffffff<br /> [ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09:<br /> 0000000000000000<br /> [ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12:<br /> 0000000000000000<br /> [ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15:<br /> ffff888104dc80a8<br /> [ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000)<br /> knlGS:0000000000000000<br /> [ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4:<br /> 00000000000006f0<br /> [ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br /> 0000000000000000<br /> [ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:<br /> 0000000000000400<br /> [ 3.362175 ] Call Trace:<br /> [ 3.362175 ] nj_release+0x51/0x1e0<br /> [ 3.362175 ] nj_probe+0x450/0x950<br /> [ 3.362175 ] ? pci_device_remove+0x110/0x110<br /> [ 3.362175 ] local_pci_probe+0x45/0xa0<br /> [ 3.362175 ] pci_device_probe+0x12b/0x1d0<br /> [ 3.362175 ] really_probe+0x2a9/0x610<br /> [ 3.362175 ] driver_probe_device+0x90/0x1d0<br /> [ 3.362175 ] ? mutex_lock_nested+0x1b/0x20<br /> [ 3.362175 ] device_driver_attach+0x68/0x70<br /> [ 3.362175 ] __driver_attach+0x124/0x1b0<br /> [ 3.362175 ] ? device_driver_attach+0x70/0x70<br /> [ 3.362175 ] bus_for_each_dev+0xbb/0x110<br /> [ 3.362175 ] ? rdinit_setup+0x45/0x45<br /> [ 3.362175 ] driver_attach+0x27/0x30<br /> [ 3.362175 ] bus_add_driver+0x1eb/0x2a0<br /> [ 3.362175 ] driver_register+0xa9/0x180<br /> [ 3.362175 ] __pci_register_driver+0x82/0x90<br /> [ 3.362175 ] ? w6692_init+0x38/0x38<br /> [ 3.362175 ] nj_init+0x36/0x38<br /> [ 3.362175 ] do_one_initcall+0x7f/0x3d0<br /> [ 3.362175 ] ? rdinit_setup+0x45/0x45<br /> [ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80<br /> [ 3.362175 ] kernel_init_freeable+0x2aa/0x301<br /> [ 3.362175 ] ? rest_init+0x2c0/0x2c0<br /> [ 3.362175 ] kernel_init+0x18/0x190<br /> [ 3.362175 ] ? rest_init+0x2c0/0x2c0<br /> [ 3.362175 ] ? rest_init+0x2c0/0x2c0<br /> [ 3.362175 ] ret_from_fork+0x1f/0x30<br /> [ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ...<br /> [ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted<br /> 5.13.0-rc1-00144-g25a1298726e #13<br /> [ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS<br /> rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014<br /> [ 3.362175 ] Call Trace:<br /> [ 3.362175 ] dump_stack+0xba/0xf5<br /> [ 3.362175 ] ? free_irq+0x100/0x480<br /> [ 3.362175 ] panic+0x15a/0x3f2<br /> [ 3.362175 ] ? __warn+0xf2/0x150<br /> [ 3.362175 ] ? free_irq+0x100/0x480<br /> [ 3.362175 ] __warn+0x108/0x150<br /> [ 3.362175 ] ? free_irq+0x100/0x480<br /> [ 3.362175 ] report_bug+0x119/0x1c0<br /> [ 3.362175 ] handle_bug+0x3b/0x80<br /> [ 3.362175 ] exc_invalid_op+0x18/0x70<br /> [ 3.362175 ] asm_exc_invalid_op+0x12/0x20<br /> [ 3.362175 ] RIP: 0010:free_irq+0x100<br /> ---truncated---

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 /> bus: mhi: core: Validate channel ID when processing command completions<br /> <br /> MHI reads the channel ID from the event ring element sent by the<br /> device which can be any value between 0 and 255. In order to<br /> prevent any out of bound accesses, add a check against the maximum<br /> number of channels supported by the controller and those channels<br /> not configured yet so as to skip processing of that event ring<br /> element.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: auxiliary bus: Fix memory leak when driver_register() fail<br /> <br /> If driver_register() returns with error we need to free the memory<br /> allocated for auxdrv-&gt;driver.name before returning from<br /> __auxiliary_driver_register()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()<br /> <br /> Fix an 11-year old bug in ngene_command_config_free_buf() while<br /> addressing the following warnings caught with -Warray-bounds:<br /> <br /> arch/alpha/include/asm/string.h:22:16: warning: &amp;#39;__builtin_memcpy&amp;#39; offset [12, 16] from the object at &amp;#39;com&amp;#39; is out of the bounds of referenced subobject &amp;#39;config&amp;#39; with type &amp;#39;unsigned char&amp;#39; at offset 10 [-Warray-bounds]<br /> arch/x86/include/asm/string_32.h:182:25: warning: &amp;#39;__builtin_memcpy&amp;#39; offset [12, 16] from the object at &amp;#39;com&amp;#39; is out of the bounds of referenced subobject &amp;#39;config&amp;#39; with type &amp;#39;unsigned char&amp;#39; at offset 10 [-Warray-bounds]<br /> <br /> The problem is that the original code is trying to copy 6 bytes of<br /> data into a one-byte size member _config_ of the wrong structue<br /> FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a<br /> legitimate compiler warning because memcpy() overruns the length<br /> of &amp;com.cmd.ConfigureBuffers.config. It seems that the right<br /> structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains<br /> 6 more members apart from the header _hdr_. Also, the name of<br /> the function ngene_command_config_free_buf() suggests that the actual<br /> intention is to ConfigureFreeBuffers, instead of ConfigureBuffers<br /> (which takes place in the function ngene_command_config_buf(), above).<br /> <br /> Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS<br /> into new struct config, and use &amp;com.cmd.ConfigureFreeBuffers.config as<br /> the destination address, instead of &amp;com.cmd.ConfigureBuffers.config,<br /> when calling memcpy().<br /> <br /> This also helps with the ongoing efforts to globally enable<br /> -Warray-bounds and get us closer to being able to tighten the<br /> FORTIFY_SOURCE routines on memcpy().