Vulnerabilities

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 /> 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 /> 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 /> 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 /> 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 /> mISDN: fix misuse of put_device() in mISDN_register_device()<br /> <br /> We should not release reference by put_device() before calling device_initialize().

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 /> erofs: fix missing xas_retry() in fscache mode<br /> <br /> The xarray iteration only holds the RCU read lock and thus may encounter<br /> XA_RETRY_ENTRY if there&amp;#39;s process modifying the xarray concurrently.<br /> This will cause oops when referring to the invalid entry.<br /> <br /> Fix this by adding the missing xas_retry(), which will make the<br /> iteration wind back to the root node if XA_RETRY_ENTRY is encountered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcm: close race conditions on sk_receive_queue<br /> <br /> sk-&gt;sk_receive_queue is protected by skb queue lock, but for KCM<br /> sockets its RX path takes mux-&gt;rx_lock to protect more than just<br /> skb queue. However, kcm_recvmsg() still only grabs the skb queue<br /> lock, so race conditions still exist.<br /> <br /> We can teach kcm_recvmsg() to grab mux-&gt;rx_lock too but this would<br /> introduce a potential performance regression as struct kcm_mux can<br /> be shared by multiple KCM sockets.<br /> <br /> So we have to enforce skb queue lock in requeue_rx_msgs() and handle<br /> skb peek case carefully in kcm_wait_data(). Fortunately,<br /> skb_recv_datagram() already handles it nicely and is widely used by<br /> other sockets, we can just switch to skb_recv_datagram() after<br /> getting rid of the unnecessary sock lock in kcm_recvmsg() and<br /> kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,<br /> so it is safe to get rid of this check too.<br /> <br /> I ran the original syzbot reproducer for 30 min without seeing any<br /> issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ena: Fix error handling in ena_init()<br /> <br /> The ena_init() won&amp;#39;t destroy workqueue created by<br /> create_singlethread_workqueue() when pci_register_driver() failed.<br /> Call destroy_workqueue() when pci_register_driver() failed to prevent the<br /> resource leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bridge: switchdev: Fix memory leaks when changing VLAN protocol<br /> <br /> The bridge driver can offload VLANs to the underlying hardware either<br /> via switchdev or the 8021q driver. When the former is used, the VLAN is<br /> marked in the bridge driver with the &amp;#39;BR_VLFLAG_ADDED_BY_SWITCHDEV&amp;#39;<br /> private flag.<br /> <br /> To avoid the memory leaks mentioned in the cited commit, the bridge<br /> driver will try to delete a VLAN via the 8021q driver if the VLAN is not<br /> marked with the previously mentioned flag.<br /> <br /> When the VLAN protocol of the bridge changes, switchdev drivers are<br /> notified via the &amp;#39;SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL&amp;#39; attribute, but<br /> the 8021q driver is also called to add the existing VLANs with the new<br /> protocol and delete them with the old protocol.<br /> <br /> In case the VLANs were offloaded via switchdev, the above behavior is<br /> both redundant and buggy. Redundant because the VLANs are already<br /> programmed in hardware and drivers that support VLAN protocol change<br /> (currently only mlx5) change the protocol upon the switchdev attribute<br /> notification. Buggy because the 8021q driver is called despite these<br /> VLANs being marked with &amp;#39;BR_VLFLAG_ADDED_BY_SWITCHDEV&amp;#39;. This leads to<br /> memory leaks [1] when the VLANs are deleted.<br /> <br /> Fix by not calling the 8021q driver for VLANs that were already<br /> programmed via switchdev.<br /> <br /> [1]<br /> unreferenced object 0xffff8881f6771200 (size 256):<br /> comm "ip", pid 446855, jiffies 4298238841 (age 55.240s)<br /> hex dump (first 32 bytes):<br /> 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] vlan_vid_add+0x437/0x750<br /> [] __br_vlan_set_proto+0x289/0x920<br /> [] br_changelink+0x3d6/0x13f0<br /> [] __rtnl_newlink+0x8ae/0x14c0<br /> [] rtnl_newlink+0x5f/0x90<br /> [] rtnetlink_rcv_msg+0x336/0xa00<br /> [] netlink_rcv_skb+0x11d/0x340<br /> [] netlink_unicast+0x438/0x710<br /> [] netlink_sendmsg+0x788/0xc40<br /> [] sock_sendmsg+0xb0/0xe0<br /> [] ____sys_sendmsg+0x4ff/0x6d0<br /> [] ___sys_sendmsg+0x12e/0x1b0<br /> [] __sys_sendmsg+0xab/0x130<br /> [] do_syscall_64+0x3d/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0

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.