Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: move page table sync declarations to linux/pgtable.h<br /> <br /> During our internal testing, we started observing intermittent boot<br /> failures when the machine uses 4-level paging and has a large amount of<br /> persistent memory:<br /> <br /> BUG: unable to handle page fault for address: ffffe70000000034<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0 <br /> Oops: 0002 [#1] SMP NOPTI<br /> RIP: 0010:__init_single_page+0x9/0x6d<br /> Call Trace:<br /> <br /> __init_zone_device_page+0x17/0x5d<br /> memmap_init_zone_device+0x154/0x1bb<br /> pagemap_range+0x2e0/0x40f<br /> memremap_pages+0x10b/0x2f0<br /> devm_memremap_pages+0x1e/0x60<br /> dev_dax_probe+0xce/0x2ec [device_dax]<br /> dax_bus_probe+0x6d/0xc9<br /> [... snip ...]<br /> <br /> <br /> It turns out that the kernel panics while initializing vmemmap (struct<br /> page array) when the vmemmap region spans two PGD entries, because the new<br /> PGD entry is only installed in init_mm.pgd, but not in the page tables of<br /> other tasks.<br /> <br /> And looking at __populate_section_memmap():<br /> if (vmemmap_can_optimize(altmap, pgmap)) <br /> // does not sync top level page tables<br /> r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);<br /> else <br /> // sync top level page tables in x86<br /> r = vmemmap_populate(start, end, nid, altmap);<br /> <br /> In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c<br /> synchronizes the top level page table (See commit 9b861528a801 ("x86-64,<br /> mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so<br /> that all tasks in the system can see the new vmemmap area.<br /> <br /> However, when vmemmap_can_optimize() returns true, the optimized path<br /> skips synchronization of top-level page tables. This is because<br /> vmemmap_populate_compound_pages() is implemented in core MM code, which<br /> does not handle synchronization of the top-level page tables. Instead,<br /> the core MM has historically relied on each architecture to perform this<br /> synchronization manually.<br /> <br /> We&amp;#39;re not the first party to encounter a crash caused by not-sync&amp;#39;d top<br /> level page tables: earlier this year, Gwan-gyeong Mun attempted to address<br /> the issue [1] [2] after hitting a kernel panic when x86 code accessed the<br /> vmemmap area before the corresponding top-level entries were synced. At<br /> that time, the issue was believed to be triggered only when struct page<br /> was enlarged for debugging purposes, and the patch did not get further<br /> updates.<br /> <br /> It turns out that current approach of relying on each arch to handle the<br /> page table sync manually is fragile because 1) it&amp;#39;s easy to forget to sync<br /> the top level page table, and 2) it&amp;#39;s also easy to overlook that the<br /> kernel should not access the vmemmap and direct mapping areas before the<br /> sync.<br /> <br /> # The solution: Make page table sync more code robust and harder to miss<br /> <br /> To address this, Dave Hansen suggested [3] [4] introducing<br /> {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables<br /> and allow each architecture to explicitly perform synchronization when<br /> installing top-level entries. With this approach, we no longer need to<br /> worry about missing the sync step, reducing the risk of future<br /> regressions.<br /> <br /> The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,<br /> PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by<br /> vmalloc and ioremap to synchronize page tables.<br /> <br /> pgd_populate_kernel() looks like this:<br /> static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,<br /> p4d_t *p4d)<br /> {<br /> pgd_populate(&amp;init_mm, pgd, p4d);<br /> if (ARCH_PAGE_TABLE_SYNC_MASK &amp; PGTBL_PGD_MODIFIED)<br /> arch_sync_kernel_mappings(addr, addr);<br /> }<br /> <br /> It is worth noting that vmalloc() and apply_to_range() carefully<br /> synchronizes page tables by calling p*d_alloc_track() and<br /> arch_sync_kernel_mappings(), and thus they are not affected by<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: slub: avoid wake up kswapd in set_track_prepare<br /> <br /> set_track_prepare() can incur lock recursion.<br /> The issue is that it is called from hrtimer_start_range_ns<br /> holding the per_cpu(hrtimer_bases)[n].lock, but when enabled<br /> CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare,<br /> and try to hold the per_cpu(hrtimer_bases)[n].lock.<br /> <br /> Avoid deadlock caused by implicitly waking up kswapd by passing in<br /> allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the<br /> debug_objects_fill_pool() case. Inside stack depot they are processed by<br /> gfp_nested_mask().<br /> Since ___slab_alloc() has preemption disabled, we mask out<br /> __GFP_DIRECT_RECLAIM from the flags there.<br /> <br /> The oops looks something like:<br /> <br /> BUG: spinlock recursion on CPU#3, swapper/3/0<br /> lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3<br /> Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT)<br /> Call trace:<br /> spin_bug+0x0<br /> _raw_spin_lock_irqsave+0x80<br /> hrtimer_try_to_cancel+0x94<br /> task_contending+0x10c<br /> enqueue_dl_entity+0x2a4<br /> dl_server_start+0x74<br /> enqueue_task_fair+0x568<br /> enqueue_task+0xac<br /> do_activate_task+0x14c<br /> ttwu_do_activate+0xcc<br /> try_to_wake_up+0x6c8<br /> default_wake_function+0x20<br /> autoremove_wake_function+0x1c<br /> __wake_up+0xac<br /> wakeup_kswapd+0x19c<br /> wake_all_kswapds+0x78<br /> __alloc_pages_slowpath+0x1ac<br /> __alloc_pages_noprof+0x298<br /> stack_depot_save_flags+0x6b0<br /> stack_depot_save+0x14<br /> set_track_prepare+0x5c<br /> ___slab_alloc+0xccc<br /> __kmalloc_cache_noprof+0x470<br /> __set_page_owner+0x2bc<br /> post_alloc_hook[jt]+0x1b8<br /> prep_new_page+0x28<br /> get_page_from_freelist+0x1edc<br /> __alloc_pages_noprof+0x13c<br /> alloc_slab_page+0x244<br /> allocate_slab+0x7c<br /> ___slab_alloc+0x8e8<br /> kmem_cache_alloc_noprof+0x450<br /> debug_objects_fill_pool+0x22c<br /> debug_object_activate+0x40<br /> enqueue_hrtimer[jt]+0xdc<br /> hrtimer_start_range_ns+0x5f8<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ax25: properly unshare skbs in ax25_kiss_rcv()<br /> <br /> Bernard Pidoux reported a regression apparently caused by commit<br /> c353e8983e0d ("net: introduce per netns packet chains").<br /> <br /> skb-&gt;dev becomes NULL and we crash in __netif_receive_skb_core().<br /> <br /> Before above commit, different kind of bugs or corruptions could happen<br /> without a major crash.<br /> <br /> But the root cause is that ax25_kiss_rcv() can queue/mangle input skb<br /> without checking if this skb is shared or not.<br /> <br /> Many thanks to Bernard Pidoux for his help, diagnosis and tests.<br /> <br /> We had a similar issue years ago fixed with commit 7aaed57c5c28<br /> ("phonet: properly unshare skbs in phonet_rcv()").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ppp: fix memory leak in pad_compress_skb<br /> <br /> If alloc_skb() fails in pad_compress_skb(), it returns NULL without<br /> releasing the old skb. The caller does:<br /> <br /> skb = pad_compress_skb(ppp, skb);<br /> if (!skb)<br /> goto drop;<br /> <br /> drop:<br /> kfree_skb(skb);<br /> <br /> When pad_compress_skb() returns NULL, the reference to the old skb is<br /> lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.<br /> <br /> Align pad_compress_skb() semantics with realloc(): only free the old<br /> skb if allocation and compression succeed. At the call site, use the<br /> new_skb variable so the original skb is not lost when pad_compress_skb()<br /> fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result()<br /> <br /> If the ssid-&gt;datalen is more than IEEE80211_MAX_SSID_LEN (32) it would<br /> lead to memory corruption so add some bounds checking.

A vulnerability was found in Ooma Office Business Phone App up to 7.2.2 on Android. This affects an unknown part of the component com.ooma.office2. The manipulation results in improper export of android application components. The attack needs to be approached locally. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: asus-wmi: Fix racy registrations<br /> <br /> asus_wmi_register_driver() may be called from multiple drivers<br /> concurrently, which can lead to the racy list operations, eventually<br /> corrupting the memory and hitting Oops on some ASUS machines.<br /> Also, the error handling is missing, and it forgot to unregister ACPI<br /> lps0 dev ops in the error case.<br /> <br /> This patch covers those issues by introducing a simple mutex at<br /> acpi_wmi_register_driver() &amp; *_unregister_driver, and adding the<br /> proper call of asus_s2idle_check_unregister() in the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: fix out-of-bounds read in audit_compare_dname_path()<br /> <br /> When a watch on dir=/ is combined with an fsnotify event for a<br /> single-character name directly under / (e.g., creating /a), an<br /> out-of-bounds read can occur in audit_compare_dname_path().<br /> <br /> The helper parent_len() returns 1 for "/". In audit_compare_dname_path(),<br /> when parentlen equals the full path length (1), the code sets p = path + 1<br /> and pathlen = 1 - 1 = 0. The subsequent loop then dereferences<br /> p[pathlen - 1] (i.e., p[-1]), causing an out-of-bounds read.<br /> <br /> Fix this by adding a pathlen &gt; 0 check to the while loop condition<br /> to prevent the out-of-bounds access.<br /> <br /> [PM: subject tweak, sign-off email fixes]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: prevent release journal inode after journal shutdown<br /> <br /> Before calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already<br /> been executed in ocfs2_dismount_volume(), so osb-&gt;journal must be NULL. <br /> Therefore, the following calltrace will inevitably fail when it reaches<br /> jbd2_journal_release_jbd_inode().<br /> <br /> ocfs2_dismount_volume()-&gt;<br /> ocfs2_delete_osb()-&gt;<br /> ocfs2_free_slot_info()-&gt;<br /> __ocfs2_free_slot_info()-&gt;<br /> evict()-&gt;<br /> ocfs2_evict_inode()-&gt;<br /> ocfs2_clear_inode()-&gt;<br /> jbd2_journal_release_jbd_inode(osb-&gt;journal-&gt;j_journal,<br /> <br /> Adding osb-&gt;journal checks will prevent null-ptr-deref during the above<br /> execution path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix buffer free/clear order in deferred receive path<br /> <br /> Fix a use-after-free window by correcting the buffer release sequence in<br /> the deferred receive path. The code freed the RQ buffer first and only<br /> then cleared the context pointer under the lock. Concurrent paths (e.g.,<br /> ABTS and the repost path) also inspect and release the same pointer under<br /> the lock, so the old order could lead to double-free/UAF.<br /> <br /> Note that the repost path already uses the correct pattern: detach the<br /> pointer under the lock, then free it after dropping the lock. The<br /> deferred path should do the same.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: fix OOB read/write in network-coding decode<br /> <br /> batadv_nc_skb_decode_packet() trusts coded_len and checks only against<br /> skb-&gt;len. XOR starts at sizeof(struct batadv_unicast_packet), reducing<br /> payload headroom, and the source skb length is not verified, allowing an<br /> out-of-bounds read and a small out-of-bounds write.<br /> <br /> Validate that coded_len fits within the payload area of both destination<br /> and source sk_buffs before XORing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: prevent NULL pointer dereference in UTF16 conversion<br /> <br /> There can be a NULL pointer dereference bug here. NULL is passed to<br /> __cifs_sfu_make_node without checks, which passes it unchecked to<br /> cifs_strndup_to_utf16, which in turn passes it to<br /> cifs_local_to_utf16_bytes where &amp;#39;*from&amp;#39; is dereferenced, causing a crash.<br /> <br /> This patch adds a check for NULL &amp;#39;src&amp;#39; in cifs_strndup_to_utf16 and<br /> returns NULL early to prevent dereferencing NULL pointer.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE