Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: liteuart: fix use-after-free and memleak on unbind<br /> <br /> Deregister the port when unbinding the driver to prevent it from being<br /> used after releasing the driver data and leaking memory allocated by<br /> serial core.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: liteuart: Fix NULL pointer dereference in -&gt;remove()<br /> <br /> drvdata has to be set in _probe() - otherwise platform_get_drvdata()<br /> causes null pointer dereference BUG in _remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: core: fix transmit-buffer reset and memleak<br /> <br /> Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use<br /> tty_port_close") converted serial core to use tty_port_close() but<br /> failed to notice that the transmit buffer still needs to be freed on<br /> final close.<br /> <br /> Not freeing the transmit buffer means that the buffer is no longer<br /> cleared on next open so that any ioctl() waiting for the buffer to drain<br /> might wait indefinitely (e.g. on termios changes) or that stale data can<br /> end up being transmitted in case tx is restarted.<br /> <br /> Furthermore, the buffer of any port that has been opened would leak on<br /> driver unbind.<br /> <br /> Note that the port lock is held when clearing the buffer pointer due to<br /> the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race<br /> between uart_put_char() and uart_shutdown()").<br /> <br /> Also note that the tty-port shutdown() callback is not called for<br /> console ports so it is not strictly necessary to free the buffer page<br /> after releasing the lock (cf. d72402145ace ("tty/serial: do not free<br /> trasnmit buffer page under port lock")).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdnsp: Fix a NULL pointer dereference in cdnsp_endpoint_init()<br /> <br /> In cdnsp_endpoint_init(), cdnsp_ring_alloc() is assigned to pep-&gt;ring<br /> and there is a dereference of it in cdnsp_endpoint_init(), which could<br /> lead to a NULL pointer dereference on failure of cdnsp_ring_alloc().<br /> <br /> Fix this bug by adding a check of pep-&gt;ring.<br /> <br /> This bug was found by a static analyzer. The analysis employs<br /> differential checking to identify inconsistent security operations<br /> (e.g., checks or kfrees) between two code paths and confirms that the<br /> inconsistent operations are not recovered in the current function or<br /> the callers, so they constitute bugs.<br /> <br /> Note that, as a bug found by static analysis, it can be a false<br /> positive or hard to trigger. Multiple researchers have cross-reviewed<br /> the bug.<br /> <br /> Builds with CONFIG_USB_CDNSP_GADGET=y show no new warnings,<br /> and our static analyzer no longer warns about this code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iwlwifi: Fix memory leaks in error handling path<br /> <br /> Should an error occur (invalid TLV len or memory allocation failure), the<br /> memory already allocated in &amp;#39;reduce_power_data&amp;#39; should be freed before<br /> returning, otherwise it is leaking.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: pch_can: pch_can_rx_normal: fix use after free<br /> <br /> After calling netif_receive_skb(skb), dereferencing skb is unsafe.<br /> Especially, the can_frame cf which aliases skb memory is dereferenced<br /> just after the call netif_receive_skb(skb).<br /> <br /> Reordering the lines solves the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: sja1000: fix use after free in ems_pcmcia_add_card()<br /> <br /> If the last channel is not available then "dev" is freed. Fortunately,<br /> we can just use "pdev-&gt;irq" instead.<br /> <br /> Also we should check if at least one channel was set up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: bigbenff: prevent null pointer dereference<br /> <br /> When emulating the device through uhid, there is a chance we don&amp;#39;t have<br /> output reports and so report_field is null.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/hfi1: Fix leak of rcvhdrtail_dummy_kvaddr<br /> <br /> This buffer is currently allocated in hfi1_init():<br /> <br /> if (reinit)<br /> ret = init_after_reset(dd);<br /> else<br /> ret = loadtime_init(dd);<br /> if (ret)<br /> goto done;<br /> <br /> /* allocate dummy tail memory for all receive contexts */<br /> dd-&gt;rcvhdrtail_dummy_kvaddr = dma_alloc_coherent(&amp;dd-&gt;pcidev-&gt;dev,<br /> sizeof(u64),<br /> &amp;dd-&gt;rcvhdrtail_dummy_dma,<br /> GFP_KERNEL);<br /> <br /> if (!dd-&gt;rcvhdrtail_dummy_kvaddr) {<br /> dd_dev_err(dd, "cannot allocate dummy tail memory\n");<br /> ret = -ENOMEM;<br /> goto done;<br /> }<br /> <br /> The reinit triggered path will overwrite the old allocation and leak it.<br /> <br /> Fix by moving the allocation to hfi1_alloc_devdata() and the deallocation<br /> to hfi1_free_devdata().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: liteuart: fix minor-number leak on probe errors<br /> <br /> Make sure to release the allocated minor number before returning on<br /> probe errors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfp: Fix memory leak in nfp_cpp_area_cache_add()<br /> <br /> In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a<br /> CPP area structure. But in line 807 (#2), when the cache is allocated<br /> failed, this CPP area structure is not freed, which will result in<br /> memory leak.<br /> <br /> We can fix it by freeing the CPP area when the cache is allocated<br /> failed (#2).<br /> <br /> 792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size)<br /> 793 {<br /> 794 struct nfp_cpp_area_cache *cache;<br /> 795 struct nfp_cpp_area *area;<br /> <br /> 800 area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0),<br /> 801 0, size);<br /> // #1: allocates and initializes<br /> <br /> 802 if (!area)<br /> 803 return -ENOMEM;<br /> <br /> 805 cache = kzalloc(sizeof(*cache), GFP_KERNEL);<br /> 806 if (!cache)<br /> 807 return -ENOMEM; // #2: missing free<br /> <br /> 817 return 0;<br /> 818 }

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: do not perform operations on net devices being unregistered<br /> <br /> There is a short period between a net device starts to be unregistered<br /> and when it is actually gone. In that time frame ethtool operations<br /> could still be performed, which might end up in unwanted or undefined<br /> behaviours[1].<br /> <br /> Do not allow ethtool operations after a net device starts its<br /> unregistration. This patch targets the netlink part as the ioctl one<br /> isn&amp;#39;t affected: the reference to the net device is taken and the<br /> operation is executed within an rtnl lock section and the net device<br /> won&amp;#39;t be found after unregister.<br /> <br /> [1] For example adding Tx queues after unregister ends up in NULL<br /> pointer exceptions and UaFs, such as:<br /> <br /> BUG: KASAN: use-after-free in kobject_get+0x14/0x90<br /> Read of size 1 at addr ffff88801961248c by task ethtool/755<br /> <br /> CPU: 0 PID: 755 Comm: ethtool Not tainted 5.15.0-rc6+ #778<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/014<br /> Call Trace:<br /> dump_stack_lvl+0x57/0x72<br /> print_address_description.constprop.0+0x1f/0x140<br /> kasan_report.cold+0x7f/0x11b<br /> kobject_get+0x14/0x90<br /> kobject_add_internal+0x3d1/0x450<br /> kobject_init_and_add+0xba/0xf0<br /> netdev_queue_update_kobjects+0xcf/0x200<br /> netif_set_real_num_tx_queues+0xb4/0x310<br /> veth_set_channels+0x1c3/0x550<br /> ethnl_set_channels+0x524/0x610