Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: ti: Add a null pointer check to the omap_prm_domain_init<br /> <br /> devm_kasprintf() returns a pointer to dynamically allocated memory<br /> which can be NULL upon failure. Ensure the allocation was successful<br /> by checking the pointer validity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()<br /> <br /> The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,<br /> as it could be caused only by two impossible conditions:<br /> <br /> - at first the search key is set up to look for a chunk tree item, with<br /> offset -1, this is an inexact search and the key-&gt;offset will contain<br /> the correct offset upon a successful search, a valid chunk tree item<br /> cannot have an offset -1<br /> <br /> - after first successful search, the found_key corresponds to a chunk<br /> item, the offset is decremented by 1 before the next loop, it&amp;#39;s<br /> impossible to find a chunk item there due to alignment and size<br /> constraints

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list()<br /> <br /> Many syzbot reports show extreme rtnl pressure, and many of them hint<br /> that smc acquires rtnl in netns creation for no good reason [1]<br /> <br /> This patch returns early from smc_pnet_net_init()<br /> if there is no netdevice yet.<br /> <br /> I am not even sure why smc_pnet_create_pnetids_list() even exists,<br /> because smc_pnet_netdev_event() is also calling<br /> smc_pnet_add_base_pnetid() when handling NETDEV_UP event.<br /> <br /> [1] extract of typical syzbot reports<br /> <br /> 2 locks held by syz-executor.3/12252:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.4/12253:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.1/12257:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.2/12261:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.0/12265:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.3/12268:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.4/12271:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.1/12274:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.2/12280:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878

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 /> media: mediatek: vcodec: adding lock to protect encoder context list<br /> <br /> Add a lock for the ctx_list, to avoid accessing a NULL pointer<br /> within the &amp;#39;vpu_enc_ipi_handler&amp;#39; function when the ctx_list has<br /> been deleted due to an unexpected behavior on the SCP IP block.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: adding lock to protect decoder context list<br /> <br /> Add a lock for the ctx_list, to avoid accessing a NULL pointer<br /> within the &amp;#39;vpu_dec_ipi_handler&amp;#39; function when the ctx_list has<br /> been deleted due to an unexpected behavior on the SCP IP block.<br /> <br /> Hardware name: Google juniper sku16 board (DT)<br /> pstate: 20400005 (nzCv daif +PAN -UAO -TCO BTYPE=--)<br /> pc : vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec]<br /> lr : scp_ipi_handler+0xd0/0x194 [mtk_scp]<br /> sp : ffffffc0131dbbd0<br /> x29: ffffffc0131dbbd0 x28: 0000000000000000<br /> x27: ffffff9bb277f348 x26: ffffff9bb242ad00<br /> x25: ffffffd2d440d3b8 x24: ffffffd2a13ff1d4<br /> x23: ffffff9bb7fe85a0 x22: ffffffc0133fbdb0<br /> x21: 0000000000000010 x20: ffffff9b050ea328<br /> x19: ffffffc0131dbc08 x18: 0000000000001000<br /> x17: 0000000000000000 x16: ffffffd2d461c6e0<br /> x15: 0000000000000242 x14: 000000000000018f<br /> x13: 000000000000004d x12: 0000000000000000<br /> x11: 0000000000000001 x10: fffffffffffffff0<br /> x9 : ffffff9bb6e793a8 x8 : 0000000000000000<br /> x7 : 0000000000000000 x6 : 000000000000003f<br /> x5 : 0000000000000040 x4 : fffffffffffffff0<br /> x3 : 0000000000000020 x2 : ffffff9bb6e79080<br /> x1 : 0000000000000010 x0 : ffffffc0131dbc08<br /> Call trace:<br /> vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec (HASH:6c3f 2)]<br /> scp_ipi_handler+0xd0/0x194 [mtk_scp (HASH:7046 3)]<br /> mt8183_scp_irq_handler+0x44/0x88 [mtk_scp (HASH:7046 3)]<br /> scp_irq_handler+0x48/0x90 [mtk_scp (HASH:7046 3)]<br /> irq_thread_fn+0x38/0x94<br /> irq_thread+0x100/0x1c0<br /> kthread+0x140/0x1fc<br /> ret_from_fork+0x10/0x30<br /> Code: 54000088 f94ca50a eb14015f 54000060 (f9400108)<br /> ---[ end trace ace43ce36cbd5c93 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception<br /> SMP: stopping secondary CPUs<br /> Kernel Offset: 0x12c4000000 from 0xffffffc010000000<br /> PHYS_OFFSET: 0xffffffe580000000<br /> CPU features: 0x08240002,2188200c<br /> Memory Limit: none

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: Fix oops when HEVC init fails<br /> <br /> The stateless HEVC decoder saves the instance pointer in the context<br /> regardless if the initialization worked or not. This caused a use after<br /> free, when the pointer is freed in case of a failure in the deinit<br /> function.<br /> Only store the instance pointer when the initialization was successful,<br /> to solve this issue.<br /> <br /> Hardware name: Acer Tomato (rev3 - 4) board (DT)<br /> pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec]<br /> lr : vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec]<br /> sp : ffff80008750bc20<br /> x29: ffff80008750bc20 x28: ffff1299f6d70000 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> x23: ffff80008750bc98 x22: 000000000000a003 x21: ffffd45c4cfae000<br /> x20: 0000000000000010 x19: ffff1299fd668310 x18: 000000000000001a<br /> x17: 000000040044ffff x16: ffffd45cb15dc648 x15: 0000000000000000<br /> x14: ffff1299c08da1c0 x13: ffffd45cb1f87a10 x12: ffffd45cb2f5fe80<br /> x11: 0000000000000001 x10: 0000000000001b30 x9 : ffffd45c4d12b488<br /> x8 : 1fffe25339380d81 x7 : 0000000000000001 x6 : ffff1299c9c06c00<br /> x5 : 0000000000000132 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000010 x1 : ffff80008750bc98 x0 : 0000000000000000<br /> Call trace:<br /> vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec]<br /> vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec]<br /> vpu_dec_deinit+0x1c/0x30 [mtk_vcodec_dec]<br /> vdec_hevc_slice_deinit+0x30/0x98 [mtk_vcodec_dec]<br /> vdec_if_deinit+0x38/0x68 [mtk_vcodec_dec]<br /> mtk_vcodec_dec_release+0x20/0x40 [mtk_vcodec_dec]<br /> fops_vcodec_release+0x64/0x118 [mtk_vcodec_dec]<br /> v4l2_release+0x7c/0x100<br /> __fput+0x80/0x2d8<br /> __fput_sync+0x58/0x70<br /> __arm64_sys_close+0x40/0x90<br /> invoke_syscall+0x50/0x128<br /> el0_svc_common.constprop.0+0x48/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x38/0xd8<br /> el0t_64_sync_handler+0xc0/0xc8<br /> el0t_64_sync+0x1a8/0x1b0<br /> Code: d503201f f9401660 b900127f b900227f (f9400400)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbmon: prevent division by zero in fb_videomode_from_videomode()<br /> <br /> The expression htotal * vtotal can have a zero value on<br /> overflow. It is necessary to prevent division by zero like in<br /> fb_var_to_videomode().<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Svace.

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 /> usb: typec: ucsi: Limit read size on v1.2<br /> <br /> Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was<br /> increased from 16 to 256. In order to avoid overflowing reads for older<br /> systems, add a mechanism to use the read UCSI version to truncate read<br /> sizes on UCSI v1.2.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: prevent division by zero in blk_rq_stat_sum()<br /> <br /> The expression dst-&gt;nr_samples + src-&gt;nr_samples may<br /> have zero value on overflow. It is necessary to add<br /> a check to avoid division by zero.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Svace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: iaa - Fix async_disable descriptor leak<br /> <br /> The disable_async paths of iaa_compress/decompress() don&amp;#39;t free idxd<br /> descriptors in the async_disable case. Currently this only happens in<br /> the testcases where req-&gt;dst is set to null. Add a test to free them<br /> in those paths.