Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: atomisp: prevent integer overflow in sh_css_set_black_frame()<br /> <br /> The "height" and "width" values come from the user so the "height * width"<br /> multiplication can overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dp: add atomic_check to bridge ops<br /> <br /> DRM commit_tails() will disable downstream crtc/encoder/bridge if<br /> both disable crtc is required and crtc-&gt;active is set before pushing<br /> a new frame downstream.<br /> <br /> There is a rare case that user space display manager issue an extra<br /> screen update immediately followed by close DRM device while down<br /> stream display interface is disabled. This extra screen update will<br /> timeout due to the downstream interface is disabled but will cause<br /> crtc-&gt;active be set. Hence the followed commit_tails() called by<br /> drm_release() will pass the disable downstream crtc/encoder/bridge<br /> conditions checking even downstream interface is disabled.<br /> This cause the crash to happen at dp_bridge_disable() due to it trying<br /> to access the main link register to push the idle pattern out while main<br /> link clocks is disabled.<br /> <br /> This patch adds atomic_check to prevent the extra frame will not<br /> be pushed down if display interface is down so that crtc-&gt;active<br /> will not be set neither. This will fail the conditions checking<br /> of disabling down stream crtc/encoder/bridge which prevent<br /> drm_release() from calling dp_bridge_disable() so that crash<br /> at dp_bridge_disable() prevented.<br /> <br /> There is no protection in the DRM framework to check if the display<br /> pipeline has been already disabled before trying again. The only<br /> check is the crtc_state-&gt;active but this is controlled by usermode<br /> using UAPI. Hence if the usermode sets this and then crashes, the<br /> driver needs to protect against double disable.<br /> <br /> SError Interrupt on CPU7, code 0x00000000be000411 -- SError<br /> CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19<br /> Hardware name: Google Lazor (rev3 - 8) (DT)<br /> pstate: a04000c9 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __cmpxchg_case_acq_32+0x14/0x2c<br /> lr : do_raw_spin_lock+0xa4/0xdc<br /> sp : ffffffc01092b6a0<br /> x29: ffffffc01092b6a0 x28: 0000000000000028 x27: 0000000000000038<br /> x26: 0000000000000004 x25: ffffffd2973dce48 x24: 0000000000000000<br /> x23: 00000000ffffffff x22: 00000000ffffffff x21: ffffffd2978d0008<br /> x20: ffffffd2978d0008 x19: ffffff80ff759fc0 x18: 0000000000000000<br /> x17: 004800a501260460 x16: 0441043b04600438 x15: 04380000089807d0<br /> x14: 07b0089807800780 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000438 x10: 00000000000007d0 x9 : ffffffd2973e09e4<br /> x8 : ffffff8092d53300 x7 : ffffff808902e8b8 x6 : 0000000000000001<br /> x5 : ffffff808902e880 x4 : 0000000000000000 x3 : ffffff80ff759fc0<br /> x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffffff80ff759fc0<br /> Kernel panic - not syncing: Asynchronous SError Interrupt<br /> CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19<br /> Hardware name: Google Lazor (rev3 - 8) (DT)<br /> Call trace:<br /> dump_backtrace.part.0+0xbc/0xe4<br /> show_stack+0x24/0x70<br /> dump_stack_lvl+0x68/0x84<br /> dump_stack+0x18/0x34<br /> panic+0x14c/0x32c<br /> nmi_panic+0x58/0x7c<br /> arm64_serror_panic+0x78/0x84<br /> do_serror+0x40/0x64<br /> el1h_64_error_handler+0x30/0x48<br /> el1h_64_error+0x68/0x6c<br /> __cmpxchg_case_acq_32+0x14/0x2c<br /> _raw_spin_lock_irqsave+0x38/0x4c<br /> lock_timer_base+0x40/0x78<br /> __mod_timer+0xf4/0x25c<br /> schedule_timeout+0xd4/0xfc<br /> __wait_for_common+0xac/0x140<br /> wait_for_completion_timeout+0x2c/0x54<br /> dp_ctrl_push_idle+0x40/0x88<br /> dp_bridge_disable+0x24/0x30<br /> drm_atomic_bridge_chain_disable+0x90/0xbc<br /> drm_atomic_helper_commit_modeset_disables+0x198/0x444<br /> msm_atomic_commit_tail+0x1d0/0x374<br /> commit_tail+0x80/0x108<br /> drm_atomic_helper_commit+0x118/0x11c<br /> drm_atomic_commit+0xb4/0xe0<br /> drm_client_modeset_commit_atomic+0x184/0x224<br /> drm_client_modeset_commit_locked+0x58/0x160<br /> drm_client_modeset_commit+0x3c/0x64<br /> __drm_fb_helper_restore_fbdev_mode_unlocked+0x98/0xac<br /> drm_fb_helper_set_par+0x74/0x80<br /> drm_fb_helper_hotplug_event+0xdc/0xe0<br /> __drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xac<br /> drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x2c<br /> drm_fb_helper_lastclose+0x20/0x2c<br /> drm_lastclose+0x44/0x6c<br /> drm_release+0x88/0xd4<br /> __fput+0x104/0x220<br /> ____fput+0x1c/0x28<br /> task_work_run+0x8c/0x100<br /> d<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix memory leak in mes self test<br /> <br /> The fences associated with mes queue have to be freed<br /> up during amdgpu_ring_fini.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_create<br /> <br /> The memory pointed to by the fs-&gt;any pointer is not freed in the error<br /> path of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak.<br /> Fix by freeing the memory in the error path, thereby making the error path<br /> identical to mlx5e_fs_tt_redirect_any_destroy().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: fix a potential overflow in sctp_ifwdtsn_skip<br /> <br /> Currently, when traversing ifwdtsn skips with _sctp_walk_ifwdtsn, it only<br /> checks the pos against the end of the chunk. However, the data left for<br /> the last pos may be

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: seqiv - Handle EBUSY correctly<br /> <br /> As it is seqiv only handles the special return value of EINPROGERSS,<br /> which means that in all other cases it will free data related to the<br /> request.<br /> <br /> However, as the caller of seqiv may specify MAY_BACKLOG, we also need<br /> to expect EBUSY and treat it in the same way. Otherwise backlogged<br /> requests will trigger a use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dcb: choose correct policy to parse DCB_ATTR_BCN<br /> <br /> The dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN],<br /> which is introduced in commit 859ee3c43812 ("DCB: Add support for DCB<br /> BCN"). Please see the comment in below code<br /> <br /> static int dcbnl_bcn_setcfg(...)<br /> {<br /> ...<br /> ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. )<br /> // !!! dcbnl_pfc_up_nest for attributes<br /> // DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs<br /> ...<br /> for (i = DCB_BCN_ATTR_RP_0; i

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 /> mm/mempolicy: fix memory leak in set_mempolicy_home_node system call<br /> <br /> When encountering any vma in the range with policy other than MPOL_BIND or<br /> MPOL_PREFERRED_MANY, an error is returned without issuing a mpol_put on<br /> the policy just allocated with mpol_dup().<br /> <br /> This allows arbitrary users to leak kernel memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> integrity: Fix memory leakage in keyring allocation error path<br /> <br /> Key restriction is allocated in integrity_init_keyring(). However, if<br /> keyring allocation failed, it is not freed, causing memory leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: fix memory leak in tcindex_set_parms<br /> <br /> Syzkaller reports a memory leak as follows:<br /> ====================================<br /> BUG: memory leak<br /> unreferenced object 0xffff88810c287f00 (size 256):<br /> comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 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 /> [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046<br /> [] kmalloc include/linux/slab.h:576 [inline]<br /> [] kmalloc_array include/linux/slab.h:627 [inline]<br /> [] kcalloc include/linux/slab.h:659 [inline]<br /> [] tcf_exts_init include/net/pkt_cls.h:250 [inline]<br /> [] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342<br /> [] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553<br /> [] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147<br /> [] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082<br /> [] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540<br /> [] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> [] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345<br /> [] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921<br /> [] sock_sendmsg_nosec net/socket.c:714 [inline]<br /> [] sock_sendmsg+0x56/0x80 net/socket.c:734<br /> [] ____sys_sendmsg+0x178/0x410 net/socket.c:2482<br /> [] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536<br /> [] __sys_sendmmsg+0x105/0x330 net/socket.c:2622<br /> [] __do_sys_sendmmsg net/socket.c:2651 [inline]<br /> [] __se_sys_sendmmsg net/socket.c:2648 [inline]<br /> [] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> ====================================<br /> <br /> Kernel uses tcindex_change() to change an existing<br /> filter properties.<br /> <br /> Yet the problem is that, during the process of changing,<br /> if `old_r` is retrieved from `p-&gt;perfect`, then<br /> kernel uses tcindex_alloc_perfect_hash() to newly<br /> allocate filter results, uses tcindex_filter_result_init()<br /> to clear the old filter result, without destroying<br /> its tcf_exts structure, which triggers the above memory leak.<br /> <br /> To be more specific, there are only two source for the `old_r`,<br /> according to the tcindex_lookup(). `old_r` is retrieved from<br /> `p-&gt;perfect`, or `old_r` is retrieved from `p-&gt;h`.<br /> <br /> * If `old_r` is retrieved from `p-&gt;perfect`, kernel uses<br /> tcindex_alloc_perfect_hash() to newly allocate the<br /> filter results. Then `r` is assigned with `cp-&gt;perfect + handle`,<br /> which is newly allocated. So condition `old_r &amp;&amp; old_r != r` is<br /> true in this situation, and kernel uses tcindex_filter_result_init()<br /> to clear the old filter result, without destroying<br /> its tcf_exts structure<br /> <br /> * If `old_r` is retrieved from `p-&gt;h`, then `p-&gt;perfect` is NULL<br /> according to the tcindex_lookup(). Considering that `cp-&gt;h`<br /> is directly copied from `p-&gt;h` and `p-&gt;perfect` is NULL,<br /> `r` is assigned with `tcindex_lookup(cp, handle)`, whose value<br /> should be the same as `old_r`, so condition `old_r &amp;&amp; old_r != r`<br /> is false in this situation, kernel ignores using<br /> tcindex_filter_result_init() to clear the old filter result.<br /> <br /> So only when `old_r` is retrieved from `p-&gt;perfect` does kernel use<br /> tcindex_filter_result_init() to clear the old filter result, which<br /> triggers the above memory leak.<br /> <br /> Considering that there already exists a tc_filter_wq workqueue<br /> to destroy the old tcindex_d<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: ismt: Fix an out-of-bounds bug in ismt_access()<br /> <br /> When the driver does not check the data from the user, the variable<br /> &amp;#39;data-&gt;block[0]&amp;#39; may be very large to cause an out-of-bounds bug.<br /> <br /> The following log can reveal it:<br /> <br /> [ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20<br /> [ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE<br /> [ 33.996475] ==================================================================<br /> [ 33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b<br /> [ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485<br /> [ 33.999450] Call Trace:<br /> [ 34.001849] memcpy+0x20/0x60<br /> [ 34.002077] ismt_access.cold+0x374/0x214b<br /> [ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0<br /> [ 34.004007] i2c_smbus_xfer+0x10a/0x390<br /> [ 34.004291] i2cdev_ioctl_smbus+0x2c8/0x710<br /> [ 34.005196] i2cdev_ioctl+0x5ec/0x74c<br /> <br /> Fix this bug by checking the size of &amp;#39;data-&gt;block[0]&amp;#39; first.