Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeon_ep: fix potential memory leak in octep_device_setup()<br /> <br /> When occur unsupported_dev and mbox init errors, it did not free oct-&gt;conf<br /> and iounmap() oct-&gt;mmio[i].hw_addr. That would trigger memory leak problem.<br /> Add kfree() for oct-&gt;conf and iounmap() for oct-&gt;mmio[i].hw_addr under<br /> unsupported_dev and mbox init errors to fix the problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp i2c: don&amp;#39;t count unused / invalid keys for flow release<br /> <br /> We&amp;#39;re currently hitting the WARN_ON in mctp_i2c_flow_release:<br /> <br /> if (midev-&gt;release_count &gt; midev-&gt;i2c_lock_count) {<br /> WARN_ONCE(1, "release count overflow");<br /> <br /> This may be hit if we expire a flow before sending the first packet it<br /> contains - as we will not be pairing the increment of release_count<br /> (performed on flow release) with the i2c lock operation (only<br /> performed on actual TX).<br /> <br /> To fix this, only release a flow if we&amp;#39;ve encountered it previously (ie,<br /> dev_flow_state does not indicate NEW), as we will mark the flow as<br /> ACTIVE at the same time as accounting for the i2c lock operation. We<br /> also need to add an INVALID flow state, to indicate when we&amp;#39;ve done the<br /> release.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mISDN: fix possible memory leak in mISDN_dsp_element_register()<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 /> use put_device() to give up the reference, so that the name can be<br /> freed in kobject_cleanup() when the refcount is 0.<br /> <br /> The &amp;#39;entry&amp;#39; is going to be freed in mISDN_dsp_dev_release(), so the<br /> kfree() is removed. list_del() is called in mISDN_dsp_dev_release(),<br /> so it need be initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix connections leak when tlink setup failed<br /> <br /> If the tlink setup failed, lost to put the connections, then<br /> the module refcnt leak since the cifsd kthread not exit.<br /> <br /> Also leak the fscache info, and for next mount with fsc, it will<br /> print the follow errors:<br /> CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST)<br /> <br /> Let&amp;#39;s check the result of tlink setup, and do some cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: libata-transport: fix error handling in ata_tdev_add()<br /> <br /> In ata_tdev_add(), the return value of transport_add_device() is<br /> not checked. As a result, it causes null-ptr-deref while removing<br /> the module, because transport_remove_device() is called to remove<br /> the device that was not added.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0<br /> CPU: 13 PID: 13603 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #36<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : device_del+0x48/0x3a0<br /> lr : device_del+0x44/0x3a0<br /> Call trace:<br /> device_del+0x48/0x3a0<br /> attribute_container_class_device_del+0x28/0x40<br /> transport_remove_classdev+0x60/0x7c<br /> attribute_container_device_trigger+0x118/0x120<br /> transport_remove_device+0x20/0x30<br /> ata_tdev_delete+0x24/0x50 [libata]<br /> ata_tlink_delete+0x40/0xa0 [libata]<br /> ata_tport_delete+0x2c/0x60 [libata]<br /> ata_port_detach+0x148/0x1b0 [libata]<br /> ata_pci_remove_one+0x50/0x80 [libata]<br /> ahci_remove_one+0x4c/0x8c [ahci]<br /> <br /> Fix this by checking and handling return value of transport_add_device()<br /> in ata_tdev_add(). In the error path, device_del() is called to delete<br /> the device which was added earlier in this function, and ata_tdev_free()<br /> is called to free ata_dev.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: libata-transport: fix error handling in ata_tlink_add()<br /> <br /> In ata_tlink_add(), the return value of transport_add_device() is<br /> not checked. As a result, it causes null-ptr-deref while removing<br /> the module, because transport_remove_device() is called to remove<br /> the device that was not added.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0<br /> CPU: 33 PID: 13850 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #12<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : device_del+0x48/0x39c<br /> lr : device_del+0x44/0x39c<br /> Call trace:<br /> device_del+0x48/0x39c<br /> attribute_container_class_device_del+0x28/0x40<br /> transport_remove_classdev+0x60/0x7c<br /> attribute_container_device_trigger+0x118/0x120<br /> transport_remove_device+0x20/0x30<br /> ata_tlink_delete+0x88/0xb0 [libata]<br /> ata_tport_delete+0x2c/0x60 [libata]<br /> ata_port_detach+0x148/0x1b0 [libata]<br /> ata_pci_remove_one+0x50/0x80 [libata]<br /> ahci_remove_one+0x4c/0x8c [ahci]<br /> <br /> Fix this by checking and handling return value of transport_add_device()<br /> in ata_tlink_add().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: libata-transport: fix error handling in ata_tport_add()<br /> <br /> In ata_tport_add(), the return value of transport_add_device() is<br /> not checked. As a result, it causes null-ptr-deref while removing<br /> the module, because transport_remove_device() is called to remove<br /> the device that was not added.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0<br /> CPU: 12 PID: 13605 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #8<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : device_del+0x48/0x39c<br /> lr : device_del+0x44/0x39c<br /> Call trace:<br /> device_del+0x48/0x39c<br /> attribute_container_class_device_del+0x28/0x40<br /> transport_remove_classdev+0x60/0x7c<br /> attribute_container_device_trigger+0x118/0x120<br /> transport_remove_device+0x20/0x30<br /> ata_tport_delete+0x34/0x60 [libata]<br /> ata_port_detach+0x148/0x1b0 [libata]<br /> ata_pci_remove_one+0x50/0x80 [libata]<br /> ahci_remove_one+0x4c/0x8c [ahci]<br /> <br /> Fix this by checking and handling return value of transport_add_device()<br /> in ata_tport_add().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix a memory leak in nvmet_auth_set_key<br /> <br /> When changing dhchap secrets we need to release the old<br /> secrets as well.<br /> <br /> kmemleak complaint:<br /> --<br /> unreferenced object 0xffff8c7f44ed8180 (size 64):<br /> comm "check", pid 7304, jiffies 4295686133 (age 72034.246s)<br /> hex dump (first 32 bytes):<br /> 44 48 48 43 2d 31 3a 30 30 3a 4c 64 4c 4f 64 71 DHHC-1:00:LdLOdq<br /> 79 56 69 67 77 48 55 32 6d 5a 59 4c 7a 35 59 38 yVigwHU2mZYLz5Y8<br /> backtrace:<br /> [] kstrdup+0x2e/0x60<br /> [] 0xffffffffc0e07ee6<br /> [] 0xffffffffc0dff783<br /> [] configfs_write_iter+0xb1/0x120<br /> [] vfs_write+0x2be/0x3c0<br /> [] ksys_write+0x5f/0xe0<br /> [] do_syscall_64+0x38/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: don&amp;#39;t leak tagger-owned storage on switch driver unbind<br /> <br /> In the initial commit dc452a471dba ("net: dsa: introduce tagger-owned<br /> storage for private and shared data"), we had a call to<br /> tag_ops-&gt;disconnect(dst) issued from dsa_tree_free(), which is called at<br /> tree teardown time.<br /> <br /> There were problems with connecting to a switch tree as a whole, so this<br /> got reworked to connecting to individual switches within the tree. In<br /> this process, tag_ops-&gt;disconnect(ds) was made to be called only from<br /> switch.c (cross-chip notifiers emitted as a result of dynamic tag proto<br /> changes), but the normal driver teardown code path wasn&amp;#39;t replaced with<br /> anything.<br /> <br /> Solve this problem by adding a function that does the opposite of<br /> dsa_switch_setup_tag_protocol(), which is called from the equivalent<br /> spot in dsa_switch_teardown(). The positioning here also ensures that we<br /> won&amp;#39;t have any use-after-free in tagging protocol (*rcv) ops, since the<br /> teardown sequence is as follows:<br /> <br /> dsa_tree_teardown<br /> -&gt; dsa_tree_teardown_master<br /> -&gt; dsa_master_teardown<br /> -&gt; unsets master-&gt;dsa_ptr, making no further packets match the<br /> ETH_P_XDSA packet type handler<br /> -&gt; dsa_tree_teardown_ports<br /> -&gt; dsa_port_teardown<br /> -&gt; dsa_slave_destroy<br /> -&gt; unregisters DSA net devices, there is even a synchronize_net()<br /> in unregister_netdevice_many()<br /> -&gt; dsa_tree_teardown_switches<br /> -&gt; dsa_switch_teardown<br /> -&gt; dsa_switch_teardown_tag_protocol<br /> -&gt; finally frees the tagger-owned storage

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/x25: Fix skb leak in x25_lapb_receive_frame()<br /> <br /> x25_lapb_receive_frame() using skb_copy() to get a private copy of<br /> skb, the new skb should be freed in the undersized/fragmented skb<br /> error handling path. Otherwise there is a memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix missing xas_retry() calls in xarray iteration<br /> <br /> netfslib has a number of places in which it performs iteration of an xarray<br /> whilst being under the RCU read lock. It *should* call xas_retry() as the<br /> first thing inside of the loop and do "continue" if it returns true in case<br /> the xarray walker passed out a special value indicating that the walk needs<br /> to be redone from the root[*].<br /> <br /> Fix this by adding the missing retry checks.<br /> <br /> [*] I wonder if this should be done inside xas_find(), xas_next_node() and<br /> suchlike, but I&amp;#39;m told that&amp;#39;s not an simple change to effect.<br /> <br /> This can cause an oops like that below. Note the faulting address - this<br /> is an internal value (|0x2) returned from xarray.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000402<br /> ...<br /> RIP: 0010:netfs_rreq_unlock+0xef/0x380 [netfs]<br /> ...<br /> Call Trace:<br /> netfs_rreq_assess+0xa6/0x240 [netfs]<br /> netfs_readpage+0x173/0x3b0 [netfs]<br /> ? init_wait_var_entry+0x50/0x50<br /> filemap_read_page+0x33/0xf0<br /> filemap_get_pages+0x2f2/0x3f0<br /> filemap_read+0xaa/0x320<br /> ? do_filp_open+0xb2/0x150<br /> ? rmqueue+0x3be/0xe10<br /> ceph_read_iter+0x1fe/0x680 [ceph]<br /> ? new_sync_read+0x115/0x1a0<br /> new_sync_read+0x115/0x1a0<br /> vfs_read+0xf3/0x180<br /> ksys_read+0x5f/0xe0<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Changes:<br /> ========<br /> ver #2)<br /> - Changed an unsigned int to a size_t to reduce the likelihood of an<br /> overflow as per Willy&amp;#39;s suggestion.<br /> - Added an additional patch to fix the maths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drbd: use after free in drbd_create_device()<br /> <br /> The drbd_destroy_connection() frees the "connection" so use the _safe()<br /> iterator to prevent a use after free.