Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix xid leak in cifs_flock()<br /> <br /> If not flock, before return -ENOLCK, should free the xid,<br /> otherwise, the xid will be leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: ti: am65-cpsw: Fix PM runtime leakage in am65_cpsw_nuss_ndo_slave_open()<br /> <br /> Ensure pm_runtime_put() is issued in error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: vpe-mt: fix possible memory leak while module exiting<br /> <br /> Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device&amp;#39;s<br /> bus_id string array"), the name of device is allocated dynamically,<br /> it need be freed when module exiting, call put_device() to give up<br /> reference, so that it can be freed in kobject_cleanup() when the<br /> refcount hit to 0. The vpe_device is static, so remove kfree() from<br /> vpe_device_release().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/52xx: Fix a resource leak in an error handling path<br /> <br /> The error handling path of mpc52xx_lpbfifo_probe() has a request_irq()<br /> that is not balanced by a corresponding free_irq().<br /> <br /> Add the missing call, as already done in the remove function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7915: Fix PCI device refcount leak in mt7915_pci_init_hif2()<br /> <br /> As comment of pci_get_device() says, it returns a pci_device with its<br /> refcount increased. We need to call pci_dev_put() to decrease the<br /> refcount. Save the return value of pci_get_device() and call<br /> pci_dev_put() to decrease the refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: tegra: Fix refcount leak in tegra210_clock_init<br /> <br /> of_find_matching_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()<br /> <br /> Fix a NULL pointer crash that occurs when we are freeing the socket at the<br /> same time we access it via sysfs.<br /> <br /> The problem is that:<br /> <br /> 1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take<br /> the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold()<br /> does a get on the "struct sock".<br /> <br /> 2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put<br /> on the "struct socket" and that does __sock_release() which sets the<br /> sock-&gt;ops to NULL.<br /> <br /> 3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then<br /> call kernel_getpeername() which accesses the NULL sock-&gt;ops.<br /> <br /> Above we do a get on the "struct sock", but we needed a get on the "struct<br /> socket". Originally, we just held the frwd_lock the entire time but in<br /> commit bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock while<br /> calling getpeername()") we switched to refcount based because the network<br /> layer changed and started taking a mutex in that path, so we could no<br /> longer hold the frwd_lock.<br /> <br /> Instead of trying to maintain multiple refcounts, this just has us use a<br /> mutex for accessing the socket in the interface code paths.

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 /> fs/ntfs3: Fix memory leak on ntfs_fill_super() error path<br /> <br /> syzbot reported kmemleak as below:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff8880122f1540 (size 32):<br /> comm "a.out", pid 6664, jiffies 4294939771 (age 25.500s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 ed ff ed ff 00 00 00 00 ................<br /> backtrace:<br /> [] ntfs_init_fs_context+0x22/0x1c0<br /> [] alloc_fs_context+0x217/0x430<br /> [] path_mount+0x704/0x1080<br /> [] __x64_sys_mount+0x18c/0x1d0<br /> [] do_syscall_64+0x34/0xb0<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> This patch fixes this issue by freeing mount options on error path of<br /> ntfs_fill_super().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: cake: fix null pointer access issue when cake_init() fails<br /> <br /> When the default qdisc is cake, if the qdisc of dev_queue fails to be<br /> inited during mqprio_init(), cake_reset() is invoked to clear<br /> resources. In this case, the tins is NULL, and it will cause gpf issue.<br /> <br /> The process is as follows:<br /> qdisc_create_dflt()<br /> cake_init()<br /> q-&gt;tins = kvcalloc(...) ---&gt;failed, q-&gt;tins is NULL<br /> ...<br /> qdisc_put()<br /> ...<br /> cake_reset()<br /> ...<br /> cake_dequeue_one()<br /> b = &amp;q-&gt;tins[...] ---&gt;q-&gt;tins is NULL<br /> <br /> The following is the Call Trace information:<br /> general protection fault, probably for non-canonical address<br /> 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:cake_dequeue_one+0xc9/0x3c0<br /> Call Trace:<br /> <br /> cake_reset+0xb1/0x140<br /> qdisc_reset+0xed/0x6f0<br /> qdisc_destroy+0x82/0x4c0<br /> qdisc_put+0x9e/0xb0<br /> qdisc_create_dflt+0x2c3/0x4a0<br /> mqprio_init+0xa71/0x1760<br /> qdisc_create+0x3eb/0x1000<br /> tc_modify_qdisc+0x408/0x1720<br /> rtnetlink_rcv_msg+0x38e/0xac0<br /> netlink_rcv_skb+0x12d/0x3a0<br /> netlink_unicast+0x4a2/0x740<br /> netlink_sendmsg+0x826/0xcc0<br /> sock_sendmsg+0xc5/0x100<br /> ____sys_sendmsg+0x583/0x690<br /> ___sys_sendmsg+0xe8/0x160<br /> __sys_sendmsg+0xbf/0x160<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7f89e5122d04<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: cdev: fix NULL-pointer dereferences<br /> <br /> There are several places where we can crash the kernel by requesting<br /> lines, unbinding the GPIO device, then calling any of the system calls<br /> relevant to the GPIO character device&amp;#39;s annonymous file descriptors:<br /> ioctl(), read(), poll().<br /> <br /> While I observed it with the GPIO simulator, it will also happen for any<br /> of the GPIO devices that can be hot-unplugged - for instance any HID GPIO<br /> expander (e.g. CP2112).<br /> <br /> This affects both v1 and v2 uAPI.<br /> <br /> This fixes it partially by checking if gdev-&gt;chip is not NULL but it<br /> doesn&amp;#39;t entirely remedy the situation as we still have a race condition<br /> in which another thread can remove the device after the check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: fix a use-after-free in nouveau_gem_prime_import_sg_table()<br /> <br /> nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code<br /> back to the caller. On failures, ttm will call nouveau_bo_del_ttm() and<br /> free the memory.Thus, when nouveau_bo_init() returns an error, the gem<br /> object has already been released. Then the call to nouveau_bo_ref() will<br /> use the freed "nvbo-&gt;bo" and lead to a use-after-free bug.<br /> <br /> We should delete the call to nouveau_bo_ref() to avoid the use-after-free.