Vulnerabilities

The Login as User or Customer WordPress plugin through 3.8 does not prevent users to log in as any other user on the site.

The Seriously Simple Podcasting WordPress plugin before 3.0.0 discloses the Podcast owner's email address (which by default is the admin email address) via an unauthenticated crafted request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Don&amp;#39;t unref the same fb many times by mistake due to deadlock handling<br /> <br /> If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()<br /> we proceed to unref the fb and then retry the whole thing from the top.<br /> But we forget to reset the fb pointer back to NULL, and so if we then<br /> get another error during the retry, before the fb lookup, we proceed<br /> the unref the same fb again without having gotten another reference.<br /> The end result is that the fb will (eventually) end up being freed<br /> while it&amp;#39;s still in use.<br /> <br /> Reset fb to NULL once we&amp;#39;ve unreffed it to avoid doing it again<br /> until we&amp;#39;ve done another fb lookup.<br /> <br /> This turned out to be pretty easy to hit on a DG2 when doing async<br /> flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I<br /> saw that drm_closefb() simply got stuck in a busy loop while walking<br /> the framebuffer list. Fortunately I was able to convince it to oops<br /> instead, and from there it was easier to track down the culprit.

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 the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix peer flow lists handling<br /> <br /> The cited change refactored mlx5e_tc_del_fdb_peer_flow() to only clear DUP<br /> flag when list of peer flows has become empty. However, if any concurrent<br /> user holds a reference to a peer flow (for example, the neighbor update<br /> workqueue task is updating peer flow&amp;#39;s parent encap entry concurrently),<br /> then the flow will not be removed from the peer list and, consecutively,<br /> DUP flag will remain set. Since mlx5e_tc_del_fdb_peers_flow() calls<br /> mlx5e_tc_del_fdb_peer_flow() for every possible peer index the algorithm<br /> will try to remove the flow from eswitch instances that it has never peered<br /> with causing either NULL pointer dereference when trying to remove the flow<br /> peer list head of peer_index that was never initialized or a warning if the<br /> list debug config is enabled[0].<br /> <br /> Fix the issue by always removing the peer flow from the list even when not<br /> releasing the last reference to it.<br /> <br /> [0]:<br /> <br /> [ 3102.985806] ------------[ cut here ]------------<br /> [ 3102.986223] list_del corruption, ffff888139110698-&gt;next is NULL<br /> [ 3102.986757] WARNING: CPU: 2 PID: 22109 at lib/list_debug.c:53 __list_del_entry_valid_or_report+0x4f/0xc0<br /> [ 3102.987561] Modules linked in: act_ct nf_flow_table bonding act_tunnel_key act_mirred act_skbedit vxlan cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress mlx5_vdpa vringh vhost_iotlb vdpa openvswitch nsh xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype xt_conntrack nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcg<br /> ss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5_core [last unloaded: bonding]<br /> [ 3102.991113] CPU: 2 PID: 22109 Comm: revalidator28 Not tainted 6.6.0-rc6+ #3<br /> [ 3102.991695] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 3102.992605] RIP: 0010:__list_del_entry_valid_or_report+0x4f/0xc0<br /> [ 3102.993122] Code: 39 c2 74 56 48 8b 32 48 39 fe 75 62 48 8b 51 08 48 39 f2 75 73 b8 01 00 00 00 c3 48 89 fe 48 c7 c7 48 fd 0a 82 e8 41 0b ad ff 0b 31 c0 c3 48 89 fe 48 c7 c7 70 fd 0a 82 e8 2d 0b ad ff 0f 0b<br /> [ 3102.994615] RSP: 0018:ffff8881383e7710 EFLAGS: 00010286<br /> [ 3102.995078] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000<br /> [ 3102.995670] RDX: 0000000000000001 RSI: ffff88885f89b640 RDI: ffff88885f89b640<br /> [ 3102.997188] DEL flow 00000000be367878 on port 0<br /> [ 3102.998594] RBP: dead000000000122 R08: 0000000000000000 R09: c0000000ffffdfff<br /> [ 3102.999604] R10: 0000000000000008 R11: ffff8881383e7598 R12: dead000000000100<br /> [ 3103.000198] R13: 0000000000000002 R14: ffff888139110000 R15: ffff888101901240<br /> [ 3103.000790] FS: 00007f424cde4700(0000) GS:ffff88885f880000(0000) knlGS:0000000000000000<br /> [ 3103.001486] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 3103.001986] CR2: 00007fd42e8dcb70 CR3: 000000011e68a003 CR4: 0000000000370ea0<br /> [ 3103.002596] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 3103.003190] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 3103.003787] Call Trace:<br /> [ 3103.004055] <br /> [ 3103.004297] ? __warn+0x7d/0x130<br /> [ 3103.004623] ? __list_del_entry_valid_or_report+0x4f/0xc0<br /> [ 3103.005094] ? report_bug+0xf1/0x1c0<br /> [ 3103.005439] ? console_unlock+0x4a/0xd0<br /> [ 3103.005806] ? handle_bug+0x3f/0x70<br /> [ 3103.006149] ? exc_invalid_op+0x13/0x60<br /> [ 3103.006531] ? asm_exc_invalid_op+0x16/0x20<br /> [ 3103.007430] ? __list_del_entry_valid_or_report+0x4f/0xc0<br /> [ 3103.007910] mlx5e_tc_del_fdb_peers_flow+0xcf/0x240 [mlx5_core]<br /> [ 3103.008463] mlx5e_tc_del_flow+0x46/0x270 [mlx5_core]<br /> [ 3103.008944] mlx5e_flow_put+0x26/0x50 [mlx5_core]<br /> [ 3103.009401] mlx5e_delete_flower+0x25f/0x380 [mlx5_core]<br /> [ 3103.009901] tc_setup_cb_destroy+0xab/0x180<br /> [ 3103.010292] fl_hw_destroy_filter+0x99/0xc0 [cls_flower]<br /> [ 3103.010779] __fl_delete+0x2d4/0x2f0 [cls_flower]<br /> [ 3103.0<br /> ---truncated---

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 /> 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 /> 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 /> 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 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 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 />