Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix a possible leak when destroy a ctrl during qp establishment<br /> <br /> In nvmet_sq_destroy we capture sq-&gt;ctrl early and if it is non-NULL we<br /> know that a ctrl was allocated (in the admin connect request handler)<br /> and we need to release pending AERs, clear ctrl-&gt;sqs and sq-&gt;ctrl<br /> (for nvme-loop primarily), and drop the final reference on the ctrl.<br /> <br /> However, a small window is possible where nvmet_sq_destroy starts (as<br /> a result of the client giving up and disconnecting) concurrently with<br /> the nvme admin connect cmd (which may be in an early stage). But *before*<br /> kill_and_confirm of sq-&gt;ref (i.e. the admin connect managed to get an sq<br /> live reference). In this case, sq-&gt;ctrl was allocated however after it was<br /> captured in a local variable in nvmet_sq_destroy.<br /> This prevented the final reference drop on the ctrl.<br /> <br /> Solve this by re-capturing the sq-&gt;ctrl after all inflight request has<br /> completed, where for sure sq-&gt;ctrl reference is final, and move forward<br /> based on that.<br /> <br /> This issue was observed in an environment with many hosts connecting<br /> multiple ctrls simoutanuosly, creating a delay in allocating a ctrl<br /> leading up to this race window.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr<br /> <br /> When del_timer_sync() is called in an interrupt context it throws a warning<br /> because of potential deadlock. The timer is used only to exit from<br /> wait_for_completion() after a timeout so replacing the call with<br /> wait_for_completion_timeout() allows to remove the problematic timer and<br /> its related functions altogether.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp_metrics: validate source addr length<br /> <br /> I don&amp;#39;t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4<br /> is at least 4 bytes long, and the policy doesn&amp;#39;t have an entry<br /> for this attribute at all (neither does it for IPv6 but v6 is<br /> manually validated).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bluetooth/hci: disallow setting handle bigger than HCI_CONN_HANDLE_MAX<br /> <br /> Syzbot hit warning in hci_conn_del() caused by freeing handle that was<br /> not allocated using ida allocator.<br /> <br /> This is caused by handle bigger than HCI_CONN_HANDLE_MAX passed by<br /> hci_le_big_sync_established_evt(), which makes code think it&amp;#39;s unset<br /> connection.<br /> <br /> Add same check for handle upper bound as in hci_conn_set_handle() to<br /> prevent warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Ignore too large handle values in BIG<br /> <br /> hci_le_big_sync_established_evt is necessary to filter out cases where the<br /> handle value is belonging to ida id range, otherwise ida will be erroneously<br /> released in hci_conn_cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-pci: Check if is_avq is NULL<br /> <br /> [bug]<br /> In the virtio_pci_common.c function vp_del_vqs, vp_dev-&gt;is_avq is involved<br /> to determine whether it is admin virtqueue, but this function vp_dev-&gt;is_avq<br /> may be empty. For installations, virtio_pci_legacy does not assign a value<br /> to vp_dev-&gt;is_avq.<br /> <br /> [fix]<br /> Check whether it is vp_dev-&gt;is_avq before use.<br /> <br /> [test]<br /> Test with virsh Attach device<br /> Before this patch, the following command would crash the guest system<br /> <br /> After applying the patch, everything seems to be working fine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost_task: Handle SIGKILL by flushing work and exiting<br /> <br /> Instead of lingering until the device is closed, this has us handle<br /> SIGKILL by:<br /> <br /> 1. marking the worker as killed so we no longer try to use it with<br /> new virtqueues and new flush operations.<br /> 2. setting the virtqueue to worker mapping so no new works are queued.<br /> 3. running all the exiting works.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix improper extts handling<br /> <br /> Extts events are disabled and enabled by the application ts2phc.<br /> However, in case where the driver is removed when the application is<br /> running, a specific extts event remains enabled and can cause a kernel<br /> crash.<br /> As a side effect, when the driver is reloaded and application is started<br /> again, remaining extts event for the channel from a previous run will<br /> keep firing and the message "extts on unexpected channel" might be<br /> printed to the user.<br /> <br /> To avoid that, extts events shall be disabled when PTP is released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: ISO: Check socket flag instead of hcon<br /> <br /> This fixes the following Smatch static checker warning:<br /> <br /> net/bluetooth/iso.c:1364 iso_sock_recvmsg()<br /> error: we previously assumed &amp;#39;pi-&gt;conn-&gt;hcon&amp;#39; could be null (line 1359)<br /> <br /> net/bluetooth/iso.c<br /> 1347 static int iso_sock_recvmsg(struct socket *sock, struct msghdr *msg,<br /> 1348 size_t len, int flags)<br /> 1349 {<br /> 1350 struct sock *sk = sock-&gt;sk;<br /> 1351 struct iso_pinfo *pi = iso_pi(sk);<br /> 1352<br /> 1353 BT_DBG("sk %p", sk);<br /> 1354<br /> 1355 if (test_and_clear_bit(BT_SK_DEFER_SETUP,<br /> &amp;bt_sk(sk)-&gt;flags)) {<br /> 1356 lock_sock(sk);<br /> 1357 switch (sk-&gt;sk_state) {<br /> 1358 case BT_CONNECT2:<br /> 1359 if (pi-&gt;conn-&gt;hcon &amp;&amp;<br /> ^^^^^^^^^^^^^^ If -&gt;hcon is NULL<br /> <br /> 1360 test_bit(HCI_CONN_PA_SYNC,<br /> &amp;pi-&gt;conn-&gt;hcon-&gt;flags)) {<br /> 1361 iso_conn_big_sync(sk);<br /> 1362 sk-&gt;sk_state = BT_LISTEN;<br /> 1363 } else {<br /> --&gt; 1364 iso_conn_defer_accept(pi-&gt;conn-&gt;hcon);<br /> ^^^^^^^^^^^^^^<br /> then we&amp;#39;re toast<br /> <br /> 1365 sk-&gt;sk_state = BT_CONFIG;<br /> 1366 }<br /> 1367 release_sock(sk);<br /> 1368 return 0;<br /> 1369 case BT_CONNECTED:<br /> 1370 if (test_bit(BT_SK_PA_SYNC,

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: avoid overflows in dirty throttling logic<br /> <br /> The dirty throttling logic is interspersed with assumptions that dirty<br /> limits in PAGE_SIZE units fit into 32-bit (so that various multiplications<br /> fit into 64-bits). If limits end up being larger, we will hit overflows,<br /> possible divisions by 0 etc. Fix these problems by never allowing so<br /> large dirty limits as they have dubious practical value anyway. For<br /> dirty_bytes / dirty_background_bytes interfaces we can just refuse to set<br /> so large limits. For dirty_ratio / dirty_background_ratio it isn&amp;#39;t so<br /> simple as the dirty limit is computed from the amount of available memory<br /> which can change due to memory hotplug etc. So when converting dirty<br /> limits from ratios to numbers of pages, we just don&amp;#39;t allow the result to<br /> exceed UINT_MAX.<br /> <br /> This is root-only triggerable problem which occurs when the operator<br /> sets dirty limits to &gt;16 TB.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cdrom: rearrange last_media_change check to avoid unintentional overflow<br /> <br /> When running syzkaller with the newly reintroduced signed integer wrap<br /> sanitizer we encounter this splat:<br /> <br /> [ 366.015950] UBSAN: signed-integer-overflow in ../drivers/cdrom/cdrom.c:2361:33<br /> [ 366.021089] -9223372036854775808 - 346321 cannot be represented in type &amp;#39;__s64&amp;#39; (aka &amp;#39;long long&amp;#39;)<br /> [ 366.025894] program syz-executor.4 is using a deprecated SCSI ioctl, please convert it to SG_IO<br /> [ 366.027502] CPU: 5 PID: 28472 Comm: syz-executor.7 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1<br /> [ 366.027512] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 366.027518] Call Trace:<br /> [ 366.027523] <br /> [ 366.027533] dump_stack_lvl+0x93/0xd0<br /> [ 366.027899] handle_overflow+0x171/0x1b0<br /> [ 366.038787] ata1.00: invalid multi_count 32 ignored<br /> [ 366.043924] cdrom_ioctl+0x2c3f/0x2d10<br /> [ 366.063932] ? __pm_runtime_resume+0xe6/0x130<br /> [ 366.071923] sr_block_ioctl+0x15d/0x1d0<br /> [ 366.074624] ? __pfx_sr_block_ioctl+0x10/0x10<br /> [ 366.077642] blkdev_ioctl+0x419/0x500<br /> [ 366.080231] ? __pfx_blkdev_ioctl+0x10/0x10<br /> ...<br /> <br /> Historically, the signed integer overflow sanitizer did not work in the<br /> kernel due to its interaction with `-fwrapv` but this has since been<br /> changed [1] in the newest version of Clang. It was re-enabled in the<br /> kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow<br /> sanitizer").<br /> <br /> Let&amp;#39;s rearrange the check to not perform any arithmetic, thus not<br /> tripping the sanitizer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot<br /> <br /> Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed<br /> serdev") will cause below regression issue:<br /> <br /> BT can&amp;#39;t be enabled after below steps:<br /> cold boot -&gt; enable BT -&gt; disable BT -&gt; warm reboot -&gt; BT enable failure<br /> if property enable-gpios is not configured within DT|ACPI for QCA6390.<br /> <br /> The commit is to fix a use-after-free issue within qca_serdev_shutdown()<br /> by adding condition to avoid the serdev is flushed or wrote after closed<br /> but also introduces this regression issue regarding above steps since the<br /> VSC is not sent to reset controller during warm reboot.<br /> <br /> Fixed by sending the VSC to reset controller within qca_serdev_shutdown()<br /> once BT was ever enabled, and the use-after-free issue is also fixed by<br /> this change since the serdev is still opened before it is flushed or wrote.<br /> <br /> Verified by the reported machine Dell XPS 13 9310 laptop over below two<br /> kernel commits:<br /> commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump<br /> implementation for QCA") of bluetooth-next tree.<br /> commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump<br /> implementation for QCA") of linus mainline tree.