Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses<br /> <br /> The panasonic laptop code in various places uses the SINF array with index<br /> values of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array<br /> is big enough.<br /> <br /> Not all panasonic laptops have this many SINF array entries, for example<br /> the Toughbook CF-18 model only has 10 SINF array entries. So it only<br /> supports the AC+DC brightness entries and mute.<br /> <br /> Check that the SINF array has a minimum size which covers all AC+DC<br /> brightness entries and refuse to load if the SINF array is smaller.<br /> <br /> For higher SINF indexes hide the sysfs attributes when the SINF array<br /> does not contain an entry for that attribute, avoiding show()/store()<br /> accessing the array out of bounds and add bounds checking to the probe()<br /> and resume() code accessing these.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fou: fix initialization of grc<br /> <br /> The grc must be initialize first. There can be a condition where if<br /> fou is NULL, goto out will be executed and grc would be used<br /> uninitialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info<br /> <br /> The MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the<br /> routine unconditionally frees submitted mailbox commands regardless of<br /> return status. The issue is that for MBX_TIMEOUT cases, when firmware<br /> returns SFP information at a later time, that same mailbox memory region<br /> references previously freed memory in its cmpl routine.<br /> <br /> Fix by adding checks for the MBX_TIMEOUT return code. During mailbox<br /> resource cleanup, check the mbox flag to make sure that the wait did not<br /> timeout. If the MBOX_WAKE flag is not set, then do not free the resources<br /> because it will be freed when firmware completes the mailbox at a later<br /> time in its cmpl routine.<br /> <br /> Also, increase the timeout from 30 to 60 seconds to accommodate boot<br /> scripts requiring longer timeouts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Remove SCSI host only if added<br /> <br /> If host tries to remove ufshcd driver from a UFS device it would cause a<br /> kernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before<br /> adding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host<br /> has been defered after MCQ configuration introduced by commit 0cab4023ec7b<br /> ("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported").<br /> <br /> To guarantee that SCSI host is removed only if it has been added, set the<br /> scsi_host_added flag to true after adding a SCSI host and check whether it<br /> is set or not before removing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/timerlat: Only clear timer if a kthread exists<br /> <br /> The timerlat tracer can use user space threads to check for osnoise and<br /> timer latency. If the program using this is killed via a SIGTERM, the<br /> threads are shutdown one at a time and another tracing instance can start<br /> up resetting the threads before they are fully closed. That causes the<br /> hrtimer assigned to the kthread to be shutdown and freed twice when the<br /> dying thread finally closes the file descriptors, causing a use-after-free<br /> bug.<br /> <br /> Only cancel the hrtimer if the associated thread is still around. Also add<br /> the interface_lock around the resetting of the tlat_var-&gt;kthread.<br /> <br /> Note, this is just a quick fix that can be backported to stable. A real<br /> fix is to have a better synchronization between the shutdown of old<br /> threads and the starting of new ones.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: vmalloc: ensure vmap_block is initialised before adding to queue<br /> <br /> Commit 8c61291fd850 ("mm: fix incorrect vbq reference in<br /> purge_fragmented_block") extended the &amp;#39;vmap_block&amp;#39; structure to contain a<br /> &amp;#39;cpu&amp;#39; field which is set at allocation time to the id of the initialising<br /> CPU.<br /> <br /> When a new &amp;#39;vmap_block&amp;#39; is being instantiated by new_vmap_block(), the<br /> partially initialised structure is added to the local &amp;#39;vmap_block_queue&amp;#39;<br /> xarray before the &amp;#39;cpu&amp;#39; field has been initialised. If another CPU is<br /> concurrently walking the xarray (e.g. via vm_unmap_aliases()), then it<br /> may perform an out-of-bounds access to the remote queue thanks to an<br /> uninitialised index.<br /> <br /> This has been observed as UBSAN errors in Android:<br /> <br /> | Internal error: UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP<br /> |<br /> | Call trace:<br /> | purge_fragmented_block+0x204/0x21c<br /> | _vm_unmap_aliases+0x170/0x378<br /> | vm_unmap_aliases+0x1c/0x28<br /> | change_memory_common+0x1dc/0x26c<br /> | set_memory_ro+0x18/0x24<br /> | module_enable_ro+0x98/0x238<br /> | do_init_module+0x1b0/0x310<br /> <br /> Move the initialisation of &amp;#39;vb-&gt;cpu&amp;#39; in new_vmap_block() ahead of the<br /> addition to the xarray.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Avoid race between dcn35_set_drr() and dc_state_destruct()<br /> <br /> dc_state_destruct() nulls the resource context of the DC state. The pipe<br /> context passed to dcn35_set_drr() is a member of this resource context.<br /> <br /> If dc_state_destruct() is called parallel to the IRQ processing (which<br /> calls dcn35_set_drr() at some point), we can end up using already nulled<br /> function callback fields of struct stream_resource.<br /> <br /> The logic in dcn35_set_drr() already tries to avoid this, by checking tg<br /> against NULL. But if the nulling happens exactly after the NULL check and<br /> before the next access, then we get a race.<br /> <br /> Avoid this by copying tg first to a local variable, and then use this<br /> variable for all the operations. This should work, as long as nobody<br /> frees the resource pool where the timing generators live.<br /> <br /> (cherry picked from commit 0607a50c004798a96e62c089a4c34c220179dcb5)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Avoid race between dcn10_set_drr() and dc_state_destruct()<br /> <br /> dc_state_destruct() nulls the resource context of the DC state. The pipe<br /> context passed to dcn10_set_drr() is a member of this resource context.<br /> <br /> If dc_state_destruct() is called parallel to the IRQ processing (which<br /> calls dcn10_set_drr() at some point), we can end up using already nulled<br /> function callback fields of struct stream_resource.<br /> <br /> The logic in dcn10_set_drr() already tries to avoid this, by checking tg<br /> against NULL. But if the nulling happens exactly after the NULL check and<br /> before the next access, then we get a race.<br /> <br /> Avoid this by copying tg first to a local variable, and then use this<br /> variable for all the operations. This should work, as long as nobody<br /> frees the resource pool where the timing generators live.<br /> <br /> (cherry picked from commit a3cc326a43bdc48fbdf53443e1027a03e309b643)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()<br /> <br /> We handle errors here properly, ENOMEM isn&amp;#39;t fatal, return the error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: clean up our handling of refs == 0 in snapshot delete<br /> <br /> In reada we BUG_ON(refs == 0), which could be unkind since we aren&amp;#39;t<br /> holding a lock on the extent leaf and thus could get a transient<br /> incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which<br /> could happen if we have extent tree corruption. Change that to return<br /> -EUCLEAN. In do_walk_down() we catch this case and handle it correctly,<br /> however we return -EIO, which -EUCLEAN is a more appropriate error code.<br /> Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert<br /> that to proper error handling. Also adjust the error message so we can<br /> actually do something with the information.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: line: always fill *error_out in setup_one_line()<br /> <br /> The pointer isn&amp;#39;t initialized by callers, but I have<br /> encountered cases where it&amp;#39;s still printed; initialize<br /> it in all possible cases in setup_one_line().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: rockchip: Resolve unbalanced runtime PM / system PM handling<br /> <br /> Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during<br /> NOIRQ_SYSTEM_SLEEP_PM ops") stopped respecting runtime PM status and<br /> simply disabled clocks unconditionally when suspending the system. This<br /> causes problems when the device is already runtime suspended when we go<br /> to sleep -- in which case we double-disable clocks and produce a<br /> WARNing.<br /> <br /> Switch back to pm_runtime_force_{suspend,resume}(), because that still<br /> seems like the right thing to do, and the aforementioned commit makes no<br /> explanation why it stopped using it.<br /> <br /> Also, refactor some of the resume() error handling, because it&amp;#39;s not<br /> actually a good idea to re-disable clocks on failure.