Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO<br /> <br /> The SC16IS7XX IC supports a burst mode to access the FIFOs where the<br /> initial register address is sent ($00), followed by all the FIFO data<br /> without having to resend the register address each time. In this mode, the<br /> IC doesn&amp;#39;t increment the register address for each R/W byte.<br /> <br /> The regmap_raw_read() and regmap_raw_write() are functions which can<br /> perform IO over multiple registers. They are currently used to read/write<br /> from/to the FIFO, and although they operate correctly in this burst mode on<br /> the SPI bus, they would corrupt the regmap cache if it was not disabled<br /> manually. The reason is that when the R/W size is more than 1 byte, these<br /> functions assume that the register address is incremented and handle the<br /> cache accordingly.<br /> <br /> Convert FIFO R/W functions to use the regmap _noinc_ versions in order to<br /> remove the manual cache control which was a workaround when using the<br /> _raw_ versions. FIFO registers are properly declared as volatile so<br /> cache will not be used/updated for FIFO accesses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/sparsemem: fix race in accessing memory_section-&gt;usage<br /> <br /> The below race is observed on a PFN which falls into the device memory<br /> region with the system memory configuration where PFN&amp;#39;s are such that<br /> [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL]. Since normal zone start and end<br /> pfn contains the device memory PFN&amp;#39;s as well, the compaction triggered<br /> will try on the device memory PFN&amp;#39;s too though they end up in NOP(because<br /> pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections). When<br /> from other core, the section mappings are being removed for the<br /> ZONE_DEVICE region, that the PFN in question belongs to, on which<br /> compaction is currently being operated is resulting into the kernel crash<br /> with CONFIG_SPASEMEM_VMEMAP enabled. The crash logs can be seen at [1].<br /> <br /> compact_zone() memunmap_pages<br /> ------------- ---------------<br /> __pageblock_pfn_to_page<br /> ......<br /> (a)pfn_valid():<br /> valid_section()//return true<br /> (b)__remove_pages()-&gt;<br /> sparse_remove_section()-&gt;<br /> section_deactivate():<br /> [Free the array ms-&gt;usage and set<br /> ms-&gt;usage = NULL]<br /> pfn_section_valid()<br /> [Access ms-&gt;usage which<br /> is NULL]<br /> <br /> NOTE: From the above it can be said that the race is reduced to between<br /> the pfn_valid()/pfn_section_valid() and the section deactivate with<br /> SPASEMEM_VMEMAP enabled.<br /> <br /> The commit b943f045a9af("mm/sparse: fix kernel crash with<br /> pfn_section_valid check") tried to address the same problem by clearing<br /> the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns<br /> false thus ms-&gt;usage is not accessed.<br /> <br /> Fix this issue by the below steps:<br /> <br /> a) Clear SECTION_HAS_MEM_MAP before freeing the -&gt;usage.<br /> <br /> b) RCU protected read side critical section will either return NULL<br /> when SECTION_HAS_MEM_MAP is cleared or can successfully access -&gt;usage.<br /> <br /> c) Free the -&gt;usage with kfree_rcu() and set ms-&gt;usage = NULL. No<br /> attempt will be made to access -&gt;usage after this as the<br /> SECTION_HAS_MEM_MAP is cleared thus valid_section() return false.<br /> <br /> Thanks to David/Pavan for their inputs on this patch.<br /> <br /> [1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/<br /> <br /> On Snapdragon SoC, with the mentioned memory configuration of PFN&amp;#39;s as<br /> [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of<br /> issues daily while testing on a device farm.<br /> <br /> For this particular issue below is the log. Though the below log is<br /> not directly pointing to the pfn_section_valid(){ ms-&gt;usage;}, when we<br /> loaded this dump on T32 lauterbach tool, it is pointing.<br /> <br /> [ 540.578056] Unable to handle kernel NULL pointer dereference at<br /> virtual address 0000000000000000<br /> [ 540.578068] Mem abort info:<br /> [ 540.578070] ESR = 0x0000000096000005<br /> [ 540.578073] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 540.578077] SET = 0, FnV = 0<br /> [ 540.578080] EA = 0, S1PTW = 0<br /> [ 540.578082] FSC = 0x05: level 1 translation fault<br /> [ 540.578085] Data abort info:<br /> [ 540.578086] ISV = 0, ISS = 0x00000005<br /> [ 540.578088] CM = 0, WnR = 0<br /> [ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--)<br /> [ 540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c<br /> [ 540.579454] lr : compact_zone+0x994/0x1058<br /> [ 540.579460] sp : ffffffc03579b510<br /> [ 540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c<br /> [ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640<br /> [ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000<br /> [ 540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140<br /> [ 540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff<br /> [ 540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001<br /> [ 540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440<br /> [ 540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4<br /> [ 540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: migrate: fix getting incorrect page mapping during page migration<br /> <br /> When running stress-ng testing, we found below kernel crash after a few hours:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> pc : dentry_name+0xd8/0x224<br /> lr : pointer+0x22c/0x370<br /> sp : ffff800025f134c0<br /> ......<br /> Call trace:<br /> dentry_name+0xd8/0x224<br /> pointer+0x22c/0x370<br /> vsnprintf+0x1ec/0x730<br /> vscnprintf+0x2c/0x60<br /> vprintk_store+0x70/0x234<br /> vprintk_emit+0xe0/0x24c<br /> vprintk_default+0x3c/0x44<br /> vprintk_func+0x84/0x2d0<br /> printk+0x64/0x88<br /> __dump_page+0x52c/0x530<br /> dump_page+0x14/0x20<br /> set_migratetype_isolate+0x110/0x224<br /> start_isolate_page_range+0xc4/0x20c<br /> offline_pages+0x124/0x474<br /> memory_block_offline+0x44/0xf4<br /> memory_subsys_offline+0x3c/0x70<br /> device_offline+0xf0/0x120<br /> ......<br /> <br /> After analyzing the vmcore, I found this issue is caused by page migration.<br /> The scenario is that, one thread is doing page migration, and we will use the<br /> target page&amp;#39;s -&gt;mapping field to save &amp;#39;anon_vma&amp;#39; pointer between page unmap and<br /> page move, and now the target page is locked and refcount is 1.<br /> <br /> Currently, there is another stress-ng thread performing memory hotplug,<br /> attempting to offline the target page that is being migrated. It discovers that<br /> the refcount of this target page is 1, preventing the offline operation, thus<br /> proceeding to dump the page. However, page_mapping() of the target page may<br /> return an incorrect file mapping to crash the system in dump_mapping(), since<br /> the target page-&gt;mapping only saves &amp;#39;anon_vma&amp;#39; pointer without setting<br /> PAGE_MAPPING_ANON flag.<br /> <br /> There are seveval ways to fix this issue:<br /> (1) Setting the PAGE_MAPPING_ANON flag for target page&amp;#39;s -&gt;mapping when saving<br /> &amp;#39;anon_vma&amp;#39;, but this can confuse PageAnon() for PFN walkers, since the target<br /> page has not built mappings yet.<br /> (2) Getting the page lock to call page_mapping() in __dump_page() to avoid crashing<br /> the system, however, there are still some PFN walkers that call page_mapping()<br /> without holding the page lock, such as compaction.<br /> (3) Using target page-&gt;private field to save the &amp;#39;anon_vma&amp;#39; pointer and 2 bits<br /> page state, just as page-&gt;mapping records an anonymous page, which can remove<br /> the page_mapping() impact for PFN walkers and also seems a simple way.<br /> <br /> So I choose option 3 to fix this issue, and this can also fix other potential<br /> issues for PFN walkers, such as compaction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run<br /> <br /> In mtk_jpeg_probe, &amp;jpeg-&gt;job_timeout_work is bound with<br /> mtk_jpeg_job_timeout_work.<br /> <br /> In mtk_jpeg_dec_device_run, if error happens in<br /> mtk_jpeg_set_dec_dst, it will finally start the worker while<br /> mark the job as finished by invoking v4l2_m2m_job_finish.<br /> <br /> There are two methods to trigger the bug. If we remove the<br /> module, it which will call mtk_jpeg_remove to make cleanup.<br /> The possible sequence is as follows, which will cause a<br /> use-after-free bug.<br /> <br /> CPU0 CPU1<br /> mtk_jpeg_dec_... |<br /> start worker |<br /> |mtk_jpeg_job_timeout_work<br /> mtk_jpeg_remove |<br /> v4l2_m2m_release |<br /> kfree(m2m_dev); |<br /> |<br /> | v4l2_m2m_get_curr_priv<br /> | m2m_dev-&gt;curr_ctx //use<br /> <br /> If we close the file descriptor, which will call mtk_jpeg_release,<br /> it will have a similar sequence.<br /> <br /> Fix this bug by starting timeout worker only if started jpegdec worker<br /> successfully. Then v4l2_m2m_job_finish will only be called in<br /> either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: fix NULL pointer in channel unregistration function<br /> <br /> __dma_async_device_channel_register() can fail. In case of failure,<br /> chan-&gt;local is freed (with free_percpu()), and chan-&gt;local is nullified.<br /> When dma_async_device_unregister() is called (because of managed API or<br /> intentionally by DMA controller driver), channels are unconditionally<br /> unregistered, leading to this NULL pointer:<br /> [ 1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0<br /> [...]<br /> [ 1.484499] Call trace:<br /> [ 1.486930] device_del+0x40/0x394<br /> [ 1.490314] device_unregister+0x20/0x7c<br /> [ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0<br /> <br /> Look at dma_async_device_register() function error path, channel device<br /> unregistration is done only if chan-&gt;local is not NULL.<br /> <br /> Then add the same condition at the beginning of<br /> __dma_async_device_channel_unregister() function, to avoid NULL pointer<br /> issue whatever the API used to reach this function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: host: Drop chan lock before queuing buffers<br /> <br /> Ensure read and write locks for the channel are not taken in succession by<br /> dropping the read lock from parse_xfer_event() such that a callback given<br /> to client can potentially queue buffers and acquire the write lock in that<br /> process. Any queueing of buffers should be done without channel read lock<br /> acquired as it can result in multiple locks and a soft lockup.<br /> <br /> [mani: added fixes tag and cc&amp;#39;ed stable]

In Santesoft Sante FFT Imaging versions 1.4.1 and prior once a user opens a malicious DCM file on affected FFT Imaging installations, a local attacker could perform an out-of-bounds write, which could allow for arbitrary code execution.<br /> <br />

In access_secure_service_from_temp_bond of btm_sec.cc, there is a possible way to achieve keystroke injection due to improper input validation. This could lead to remote (proximal/adjacent) escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

In attp_build_value_cmd of att_protocol.cc, there is a possible out of bounds write due to a missing bounds check. This could lead to remote code execution with no additional execution privileges needed. User interaction is not needed for exploitation.

In createSessionInternal of PackageInstallerService.java, there is a possible run-as any app due to improper input validation. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

In smp_proc_sec_req of smp_act.cc, there is a possible out of bounds read due to improper input validation. This could lead to remote (proximal/adjacent) information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.

In installExistingPackageAsUser of InstallPackageHelper.java, there is a possible carrier restriction bypass due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.