Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethernet: aeroflex: fix potential skb leak in greth_init_rings()<br /> <br /> The greth_init_rings() function won&amp;#39;t free the newly allocated skb when<br /> dma_mapping_error() returns error, so add dev_kfree_skb() to fix it.<br /> <br /> Compile tested only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: sja1105: fix memory leak in sja1105_setup_devlink_regions()<br /> <br /> When dsa_devlink_region_create failed in sja1105_setup_devlink_regions(),<br /> priv-&gt;regions is not released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hisilicon: Fix potential use-after-free in hix5hd2_rx()<br /> <br /> The skb is delivered to napi_gro_receive() which may free it, after<br /> calling this, dereferencing skb may trigger use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mdio: fix unbalanced fwnode reference count in mdio_device_release()<br /> <br /> There is warning report about of_node refcount leak<br /> while probing mdio device:<br /> <br /> OF: ERROR: memory leak, expected refcount 1 instead of 2,<br /> of_node_get()/of_node_put() unbalanced - destroy cset entry:<br /> attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4<br /> <br /> In of_mdiobus_register_device(), we increase fwnode refcount<br /> by fwnode_handle_get() before associating the of_node with<br /> mdio device, but it has never been decreased in normal path.<br /> Since that, in mdio_device_release(), it needs to call<br /> fwnode_handle_put() in addition instead of calling kfree()<br /> directly.<br /> <br /> After above, just calling mdio_device_free() in the error handle<br /> path of of_mdiobus_register_device() is enough to keep the<br /> refcount balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Fix preallocation discarding at indirect extent boundary<br /> <br /> When preallocation extent is the first one in the extent block, the<br /> code would corrupt extent tree header instead. Fix the problem and use<br /> udf_delete_aext() for deleting extent to avoid some code duplication.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix u8 overflow<br /> <br /> By keep sending L2CAP_CONF_REQ packets, chan-&gt;num_conf_rsp increases<br /> multiple times and eventually it will wrap around the maximum number<br /> (i.e., 255).<br /> This patch prevents this by adding a boundary check with<br /> L2CAP_MAX_CONF_RSP<br /> <br /> Btmon log:<br /> Bluetooth monitor ver 5.64<br /> = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594<br /> = Note: Bluetooth subsystem version 2.22 0.264636<br /> @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191<br /> = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604<br /> @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741<br /> = Open Index: 00:00:00:00:00:00 [hci0] 13.900426<br /> (...)<br /> &gt; ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106<br /> invalid packet size (12 != 1033)<br /> 08 00 01 00 02 01 04 00 01 10 ff ff ............<br /> &gt; ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561<br /> invalid packet size (14 != 1547)<br /> 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@.....<br /> &gt; ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390<br /> invalid packet size (16 != 2061)<br /> 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@.......<br /> &gt; ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932<br /> invalid packet size (16 != 2061)<br /> 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@.......<br /> = bluetoothd: Bluetooth daemon 5.43 14.401828<br /> &gt; ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753<br /> invalid packet size (12 != 1033)<br /> 08 00 01 00 04 01 04 00 40 00 00 00 ........@...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: uvc: Prevent buffer overflow in setup handler<br /> <br /> Setup function uvc_function_setup permits control transfer<br /> requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE),<br /> data stage handler for OUT transfer uses memcpy to copy req-&gt;actual<br /> bytes to uvc_event-&gt;data.data array of size 60. This may result<br /> in an overflow of 4 bytes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: Initialize mailbox message for VF reset<br /> <br /> When a MAC address is not assigned to the VF, that portion of the message<br /> sent to the VF is not set. The memory, however, is allocated from the<br /> stack meaning that information may be leaked to the VM. Initialize the<br /> message buffer to 0 so that no information is passed to the VM in this<br /> case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix perf_pending_task() UaF<br /> <br /> Per syzbot it is possible for perf_pending_task() to run after the<br /> event is free()&amp;#39;d. There are two related but distinct cases:<br /> <br /> - the task_work was already queued before destroying the event;<br /> - destroying the event itself queues the task_work.<br /> <br /> The first cannot be solved using task_work_cancel() since<br /> perf_release() itself might be called from a task_work (____fput),<br /> which means the current-&gt;task_works list is already empty and<br /> task_work_cancel() won&amp;#39;t be able to find the perf_pending_task()<br /> entry.<br /> <br /> The simplest alternative is extending the perf_event lifetime to cover<br /> the task_work.<br /> <br /> The second is just silly, queueing a task_work while you know the<br /> event is going away makes no sense and is easily avoided by<br /> re-arranging how the event is marked STATE_DEAD and ensuring it goes<br /> through STATE_OFF on the way down.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()<br /> <br /> The bounds checks in snd_soc_put_volsw_sx() are only being applied to the<br /> first channel, meaning it is possible to write out of bounds values to the<br /> second channel in stereo controls. Add appropriate checks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: mt7621: Add sentinel to quirks table<br /> <br /> Current driver is missing a sentinel in the struct soc_device_attribute<br /> array, which causes an oops when assessed by the<br /> soc_device_match(mt7621_pcie_quirks_match) call.<br /> <br /> This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr<br /> was fixed to register the SOC as a device, in:<br /> <br /> commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early")<br /> <br /> Fix it by adding the required sentinel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtc: cmos: Fix event handler registration ordering issue<br /> <br /> Because acpi_install_fixed_event_handler() enables the event<br /> automatically on success, it is incorrect to call it before the<br /> handler routine passed to it is ready to handle events.<br /> <br /> Unfortunately, the rtc-cmos driver does exactly the incorrect thing<br /> by calling cmos_wake_setup(), which passes rtc_handler() to<br /> acpi_install_fixed_event_handler(), before cmos_do_probe(), because<br /> rtc_handler() uses dev_get_drvdata() to get to the cmos object<br /> pointer and the driver data pointer is only populated in<br /> cmos_do_probe().<br /> <br /> This leads to a NULL pointer dereference in rtc_handler() on boot<br /> if the RTC fixed event happens to be active at the init time.<br /> <br /> To address this issue, change the initialization ordering of the<br /> driver so that cmos_wake_setup() is always called after a successful<br /> cmos_do_probe() call.<br /> <br /> While at it, change cmos_pnp_probe() to call cmos_do_probe() after<br /> the initial if () statement used for computing the IRQ argument to<br /> be passed to cmos_do_probe() which is cleaner than calling it in<br /> each branch of that if () (local variable "irq" can be of type int,<br /> because it is passed to that function as an argument of type int).<br /> <br /> Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check<br /> ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number<br /> of systems, because previously it only affected systems with<br /> ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that<br /> commit.