Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Free error logs of tracing instances<br /> <br /> When a tracing instance is removed, the error messages that hold errors<br /> that occurred in the instance needs to be freed. The following reports a<br /> memory leak:<br /> <br /> # cd /sys/kernel/tracing<br /> # mkdir instances/foo<br /> # echo &amp;#39;hist:keys=x&amp;#39; &gt; instances/foo/events/sched/sched_switch/trigger<br /> # cat instances/foo/error_log<br /> [ 117.404795] hist:sched:sched_switch: error: Couldn&amp;#39;t find field<br /> Command: hist:keys=x<br /> ^<br /> # rmdir instances/foo<br /> <br /> Then check for memory leaks:<br /> <br /> # echo scan &gt; /sys/kernel/debug/kmemleak<br /> # cat /sys/kernel/debug/kmemleak<br /> unreferenced object 0xffff88810d8ec700 (size 192):<br /> comm "bash", pid 869, jiffies 4294950577 (age 215.752s)<br /> hex dump (first 32 bytes):<br /> 60 dd 68 61 81 88 ff ff 60 dd 68 61 81 88 ff ff `.ha....`.ha....<br /> a0 30 8c 83 ff ff ff ff 26 00 0a 00 00 00 00 00 .0......&amp;.......<br /> backtrace:<br /> [] kmalloc_trace+0x2a/0xa0<br /> [] tracing_log_err+0x277/0x2e0<br /> [] parse_atom+0x966/0xb40<br /> [] parse_expr+0x5f3/0xdb0<br /> [] event_hist_trigger_parse+0x27f8/0x3560<br /> [] trigger_process_regex+0x135/0x1a0<br /> [] event_trigger_write+0x87/0xf0<br /> [] vfs_write+0x162/0x670<br /> [] ksys_write+0xca/0x170<br /> [] do_syscall_64+0x3e/0xc0<br /> [] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> unreferenced object 0xffff888170c35a00 (size 32):<br /> comm "bash", pid 869, jiffies 4294950577 (age 215.752s)<br /> hex dump (first 32 bytes):<br /> 0a 20 20 43 6f 6d 6d 61 6e 64 3a 20 68 69 73 74 . Command: hist<br /> 3a 6b 65 79 73 3d 78 0a 00 00 00 00 00 00 00 00 :keys=x.........<br /> backtrace:<br /> [] __kmalloc+0x4d/0x160<br /> [] tracing_log_err+0x29b/0x2e0<br /> [] parse_atom+0x966/0xb40<br /> [] parse_expr+0x5f3/0xdb0<br /> [] event_hist_trigger_parse+0x27f8/0x3560<br /> [] trigger_process_regex+0x135/0x1a0<br /> [] event_trigger_write+0x87/0xf0<br /> [] vfs_write+0x162/0x670<br /> [] ksys_write+0xca/0x170<br /> [] do_syscall_64+0x3e/0xc0<br /> [] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> The problem is that the error log needs to be freed when the instance is<br /> removed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Use number of bits to manage bitmap sizes<br /> <br /> To allocate bitmaps, the mpi3mr driver calculates sizes of bitmaps using<br /> byte as unit. However, bitmap helper functions assume that bitmaps are<br /> allocated using unsigned long as unit. This gap causes memory access beyond<br /> the bitmap sizes and results in "BUG: KASAN: slab-out-of-bounds". The BUG<br /> was observed at firmware download to eHBA-9600. Call trace indicated that<br /> the out-of-bounds access happened in find_first_zero_bit() called from<br /> mpi3mr_send_event_ack() for miroc-&gt;evtack_cmds_bitmap.<br /> <br /> To fix the BUG, do not use bytes to manage bitmap sizes. Instead, use<br /> number of bits, and call bitmap helper functions which take number of bits<br /> as arguments. For memory allocation, call bitmap_zalloc() instead of<br /> kzalloc() and krealloc(). For memory free, call bitmap_free() instead of<br /> kfree(). For zero clear, call bitmap_clear() instead of memset().<br /> <br /> Remove three fields for bitmap byte sizes in struct scmd_priv which are no<br /> longer required. Replace the field dev_handle_bitmap_sz with<br /> dev_handle_bitmap_bits to keep number of bits of removepend_bitmap across<br /> resize.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: phy: phy-tahvo: fix memory leak in tahvo_usb_probe()<br /> <br /> Smatch reports:<br /> drivers/usb/phy/phy-tahvo.c: tahvo_usb_probe()<br /> warn: missing unwind goto?<br /> <br /> After geting irq, if ret

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/dpt: Treat the DPT BO as a framebuffer<br /> <br /> Currently i915_gem_object_is_framebuffer() doesn&amp;#39;t treat the<br /> BO containing the framebuffer&amp;#39;s DPT as a framebuffer itself.<br /> This means eg. that the shrinker can evict the DPT BO while<br /> leaving the actual FB BO bound, when the DPT is allocated<br /> from regular shmem.<br /> <br /> That causes an immediate oops during hibernate as we<br /> try to rewrite the PTEs inside the already evicted<br /> DPT obj.<br /> <br /> TODO: presumably this might also be the reason for the<br /> DPT related display faults under heavy memory pressure,<br /> but I&amp;#39;m still not sure how that would happen as the object<br /> should be pinned by intel_dpt_pin() while in active use by<br /> the display engine...<br /> <br /> (cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: prevent use-after-free by freeing the cfile later<br /> <br /> In smb2_compound_op we have a possible use-after-free<br /> which can cause hard to debug problems later on.<br /> <br /> This was revealed during stress testing with KASAN enabled<br /> kernel. Fixing it by moving the cfile free call to<br /> a few lines below, after the usage.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: greybus: audio_helper: remove unused and wrong debugfs usage<br /> <br /> In the greybus audio_helper code, the debugfs file for the dapm has the<br /> potential to be removed and memory will be leaked. There is also the<br /> very real potential for this code to remove ALL debugfs entries from the<br /> system, and it seems like this is what will really happen if this code<br /> ever runs. This all is very wrong as the greybus audio driver did not<br /> create this debugfs file, the sound core did and controls the lifespan<br /> of it.<br /> <br /> So remove all of the debugfs logic from the audio_helper code as there&amp;#39;s<br /> no way it could be correct. If this really is needed, it can come back<br /> with a fixup for the incorrect usage of the debugfs_lookup() call which<br /> is what caused this to be noticed at all.

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.