Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Fix data TLB miss in sba_unmap_sg<br /> <br /> Rolf Eike Beer reported the following bug:<br /> <br /> [1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018<br /> [1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4<br /> [1274934.746891] Hardware name: 9000/785/C8000<br /> [1274934.746891]<br /> [1274934.746891] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI<br /> [1274934.746891] PSW: 00001000000001001111111000001110 Not tainted<br /> [1274934.746891] r00-03 000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000<br /> [1274934.746891] r04-07 0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001<br /> [1274934.746891] r08-11 0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001<br /> [1274934.746891] r12-15 0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0<br /> [1274934.746891] r16-19 0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007<br /> [1274934.746891] r20-23 0000000000000006 000000004a368950 0000000000000000 0000000000000001<br /> [1274934.746891] r24-27 0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0<br /> [1274934.746891] r28-31 0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118<br /> [1274934.746891] sr00-03 00000000066e5800 0000000000000000 0000000000000000 00000000066e5800<br /> [1274934.746891] sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> [1274934.746891]<br /> [1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec<br /> [1274934.746891] IIR: 48780030 ISR: 0000000000000000 IOR: 0000004140000018<br /> [1274934.746891] CPU: 3 CR30: 00000040e3a9c000 CR31: ffffffffffffffff<br /> [1274934.746891] ORIG_R28: 0000000040acdd58<br /> [1274934.746891] IAOQ[0]: sba_unmap_sg+0xb0/0x118<br /> [1274934.746891] IAOQ[1]: sba_unmap_sg+0xb4/0x118<br /> [1274934.746891] RP(r2): sba_unmap_sg+0xac/0x118<br /> [1274934.746891] Backtrace:<br /> [1274934.746891] [] dma_unmap_sg_attrs+0x6c/0x70<br /> [1274934.746891] [] scsi_dma_unmap+0x54/0x60<br /> [1274934.746891] [] mptscsih_io_done+0x150/0xd70<br /> [1274934.746891] [] mpt_interrupt+0x168/0xa68<br /> [1274934.746891] [] __handle_irq_event_percpu+0xc8/0x278<br /> [1274934.746891] [] handle_irq_event_percpu+0x3c/0xd8<br /> [1274934.746891] [] handle_percpu_irq+0xb4/0xf0<br /> [1274934.746891] [] generic_handle_irq+0x50/0x70<br /> [1274934.746891] [] call_on_stack+0x18/0x24<br /> [1274934.746891]<br /> [1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)<br /> <br /> The bug is caused by overrunning the sglist and incorrectly testing<br /> sg_dma_len(sglist) before nents. Normally this doesn&amp;#39;t cause a crash,<br /> but in this case sglist crossed a page boundary. This occurs in the<br /> following code:<br /> <br /> while (sg_dma_len(sglist) &amp;&amp; nents--) {<br /> <br /> The fix is simply to test nents first and move the decrement of nents<br /> into the loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: don&amp;#39;t try to NUMA-migrate COW pages that have other uses<br /> <br /> Oded Gabbay reports that enabling NUMA balancing causes corruption with<br /> his Gaudi accelerator test load:<br /> <br /> "All the details are in the bug, but the bottom line is that somehow,<br /> this patch causes corruption when the numa balancing feature is<br /> enabled AND we don&amp;#39;t use process affinity AND we use GUP to pin pages<br /> so our accelerator can DMA to/from system memory.<br /> <br /> Either disabling numa balancing, using process affinity to bind to<br /> specific numa-node or reverting this patch causes the bug to<br /> disappear"<br /> <br /> and Oded bisected the issue to commit 09854ba94c6a ("mm: do_wp_page()<br /> simplification").<br /> <br /> Now, the NUMA balancing shouldn&amp;#39;t actually be changing the writability<br /> of a page, and as such shouldn&amp;#39;t matter for COW. But it appears it<br /> does. Suspicious.<br /> <br /> However, regardless of that, the condition for enabling NUMA faults in<br /> change_pte_range() is nonsensical. It uses "page_mapcount(page)" to<br /> decide if a COW page should be NUMA-protected or not, and that makes<br /> absolutely no sense.<br /> <br /> The number of mappings a page has is irrelevant: not only does GUP get a<br /> reference to a page as in Oded&amp;#39;s case, but the other mappings migth be<br /> paged out and the only reference to them would be in the page count.<br /> <br /> Since we should never try to NUMA-balance a page that we can&amp;#39;t move<br /> anyway due to other references, just fix the code to use &amp;#39;page_count()&amp;#39;.<br /> Oded confirms that that fixes his issue.<br /> <br /> Now, this does imply that something in NUMA balancing ends up changing<br /> page protections (other than the obvious one of making the page<br /> inaccessible to get the NUMA faulting information). Otherwise the COW<br /> simplification wouldn&amp;#39;t matter - since doing the GUP on the page would<br /> make sure it&amp;#39;s writable.<br /> <br /> The cause of that permission change would be good to figure out too,<br /> since it clearly results in spurious COW events - but fixing the<br /> nonsensical test that just happened to work before is obviously the<br /> CorrectThing(tm) to do regardless.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/cio: verify the driver availability for path_event call<br /> <br /> If no driver is attached to a device or the driver does not provide the<br /> path_event function, an FCES path-event on this device could end up in a<br /> kernel-panic. Verify the driver availability before the path_event<br /> function call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix list corruption in perf_cgroup_switch()<br /> <br /> There&amp;#39;s list corruption on cgrp_cpuctx_list. This happens on the<br /> following path:<br /> <br /> perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list)<br /> cpu_ctx_sched_in<br /> ctx_sched_in<br /> ctx_pinned_sched_in<br /> merge_sched_in<br /> perf_cgroup_event_disable: remove the event from the list<br /> <br /> Use list_for_each_entry_safe() to allow removing an entry during<br /> iteration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: vmscan: remove deadlock due to throttling failing to make progress<br /> <br /> A soft lockup bug in kcompactd was reported in a private bugzilla with<br /> the following visible in dmesg;<br /> <br /> watchdog: BUG: soft lockup - CPU#33 stuck for 26s! [kcompactd0:479]<br /> watchdog: BUG: soft lockup - CPU#33 stuck for 52s! [kcompactd0:479]<br /> watchdog: BUG: soft lockup - CPU#33 stuck for 78s! [kcompactd0:479]<br /> watchdog: BUG: soft lockup - CPU#33 stuck for 104s! [kcompactd0:479]<br /> <br /> The machine had 256G of RAM with no swap and an earlier failed<br /> allocation indicated that node 0 where kcompactd was run was potentially<br /> unreclaimable;<br /> <br /> Node 0 active_anon:29355112kB inactive_anon:2913528kB active_file:0kB<br /> inactive_file:0kB unevictable:64kB isolated(anon):0kB isolated(file):0kB<br /> mapped:8kB dirty:0kB writeback:0kB shmem:26780kB shmem_thp:<br /> 0kB shmem_pmdmapped: 0kB anon_thp: 23480320kB writeback_tmp:0kB<br /> kernel_stack:2272kB pagetables:24500kB all_unreclaimable? yes<br /> <br /> Vlastimil Babka investigated a crash dump and found that a task<br /> migrating pages was trying to drain PCP lists;<br /> <br /> PID: 52922 TASK: ffff969f820e5000 CPU: 19 COMMAND: "kworker/u128:3"<br /> Call Trace:<br /> __schedule<br /> schedule<br /> schedule_timeout<br /> wait_for_completion<br /> __flush_work<br /> __drain_all_pages<br /> __alloc_pages_slowpath.constprop.114<br /> __alloc_pages<br /> alloc_migration_target<br /> migrate_pages<br /> migrate_to_node<br /> do_migrate_pages<br /> cpuset_migrate_mm_workfn<br /> process_one_work<br /> worker_thread<br /> kthread<br /> ret_from_fork<br /> <br /> This failure is specific to CONFIG_PREEMPT=n builds. The root of the<br /> problem is that kcompact0 is not rescheduling on a CPU while a task that<br /> has isolated a large number of the pages from the LRU is waiting on<br /> kcompact0 to reschedule so the pages can be released. While<br /> shrink_inactive_list() only loops once around too_many_isolated, reclaim<br /> can continue without rescheduling if sc-&gt;skipped_deactivate == 1 which<br /> could happen if there was no file LRU and the inactive anon list was not<br /> low.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: buffer: Fix file related error handling in IIO_BUFFER_GET_FD_IOCTL<br /> <br /> If we fail to copy the just created file descriptor to userland, we<br /> try to clean up by putting back &amp;#39;fd&amp;#39; and freeing &amp;#39;ib&amp;#39;. The code uses<br /> put_unused_fd() for the former which is wrong, as the file descriptor<br /> was already published by fd_install() which gets called internally by<br /> anon_inode_getfd().<br /> <br /> This makes the error handling code leaving a half cleaned up file<br /> descriptor table around and a partially destructed &amp;#39;file&amp;#39; object,<br /> allowing userland to play use-after-free tricks on us, by abusing<br /> the still usable fd and making the code operate on a dangling<br /> &amp;#39;file-&gt;private_data&amp;#39; pointer.<br /> <br /> Instead of leaving the kernel in a partially corrupted state, don&amp;#39;t<br /> attempt to explicitly clean up and leave this to the process exit<br /> path that&amp;#39;ll release any still valid fds, including the one created<br /> by the previous call to anon_inode_getfd(). Simply return -EFAULT to<br /> indicate the error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: ti: Fix missing sentinel for clk_div_table<br /> <br /> _get_table_maxdiv() tries to access "clk_div_table" array out of bound<br /> defined in phy-j721e-wiz.c. Add a sentinel entry to prevent<br /> the following global-out-of-bounds error reported by enabling KASAN.<br /> <br /> [ 9.552392] BUG: KASAN: global-out-of-bounds in _get_maxdiv+0xc0/0x148<br /> [ 9.558948] Read of size 4 at addr ffff8000095b25a4 by task kworker/u4:1/38<br /> [ 9.565926]<br /> [ 9.567441] CPU: 1 PID: 38 Comm: kworker/u4:1 Not tainted 5.16.0-116492-gdaadb3bd0e8d-dirty #360<br /> [ 9.576242] Hardware name: Texas Instruments J721e EVM (DT)<br /> [ 9.581832] Workqueue: events_unbound deferred_probe_work_func<br /> [ 9.587708] Call trace:<br /> [ 9.590174] dump_backtrace+0x20c/0x218<br /> [ 9.594038] show_stack+0x18/0x68<br /> [ 9.597375] dump_stack_lvl+0x9c/0xd8<br /> [ 9.601062] print_address_description.constprop.0+0x78/0x334<br /> [ 9.606830] kasan_report+0x1f0/0x260<br /> [ 9.610517] __asan_load4+0x9c/0xd8<br /> [ 9.614030] _get_maxdiv+0xc0/0x148<br /> [ 9.617540] divider_determine_rate+0x88/0x488<br /> [ 9.622005] divider_round_rate_parent+0xc8/0x124<br /> [ 9.626729] wiz_clk_div_round_rate+0x54/0x68<br /> [ 9.631113] clk_core_determine_round_nolock+0x124/0x158<br /> [ 9.636448] clk_core_round_rate_nolock+0x68/0x138<br /> [ 9.641260] clk_core_set_rate_nolock+0x268/0x3a8<br /> [ 9.645987] clk_set_rate+0x50/0xa8<br /> [ 9.649499] cdns_sierra_phy_init+0x88/0x248<br /> [ 9.653794] phy_init+0x98/0x108<br /> [ 9.657046] cdns_pcie_enable_phy+0xa0/0x170<br /> [ 9.661340] cdns_pcie_init_phy+0x250/0x2b0<br /> [ 9.665546] j721e_pcie_probe+0x4b8/0x798<br /> [ 9.669579] platform_probe+0x8c/0x108<br /> [ 9.673350] really_probe+0x114/0x630<br /> [ 9.677037] __driver_probe_device+0x18c/0x220<br /> [ 9.681505] driver_probe_device+0xac/0x150<br /> [ 9.685712] __device_attach_driver+0xec/0x170<br /> [ 9.690178] bus_for_each_drv+0xf0/0x158<br /> [ 9.694124] __device_attach+0x184/0x210<br /> [ 9.698070] device_initial_probe+0x14/0x20<br /> [ 9.702277] bus_probe_device+0xec/0x100<br /> [ 9.706223] deferred_probe_work_func+0x124/0x180<br /> [ 9.710951] process_one_work+0x4b0/0xbc0<br /> [ 9.714983] worker_thread+0x74/0x5d0<br /> [ 9.718668] kthread+0x214/0x230<br /> [ 9.721919] ret_from_fork+0x10/0x20<br /> [ 9.725520]<br /> [ 9.727032] The buggy address belongs to the variable:<br /> [ 9.732183] clk_div_table+0x24/0x440

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vt_ioctl: fix array_index_nospec in vt_setactivate<br /> <br /> array_index_nospec ensures that an out-of-bounds value is set to zero<br /> on the transient path. Decreasing the value by one afterwards causes<br /> a transient integer underflow. vsa.console should be decreased first<br /> and then sanitized with array_index_nospec.<br /> <br /> Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh<br /> Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU<br /> Amsterdam.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eeprom: ee1004: limit i2c reads to I2C_SMBUS_BLOCK_MAX<br /> <br /> Commit effa453168a7 ("i2c: i801: Don&amp;#39;t silently correct invalid transfer<br /> size") revealed that ee1004_eeprom_read() did not properly limit how<br /> many bytes to read at once.<br /> <br /> In particular, i2c_smbus_read_i2c_block_data_or_emulated() takes the<br /> length to read as an u8. If count == 256 after taking into account the<br /> offset and page boundary, the cast to u8 overflows. And this is common<br /> when user space tries to read the entire EEPROM at once.<br /> <br /> To fix it, limit each read to I2C_SMBUS_BLOCK_MAX (32) bytes, already<br /> the maximum length i2c_smbus_read_i2c_block_data_or_emulated() allows.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Fix potential use-after-free during probe<br /> <br /> Kasan has reported the following use after free on dev-&gt;iommu.<br /> when a device probe fails and it is in process of freeing dev-&gt;iommu<br /> in dev_iommu_free function, a deferred_probe_work_func runs in parallel<br /> and tries to access dev-&gt;iommu-&gt;fwspec in of_iommu_configure path thus<br /> causing use after free.<br /> <br /> BUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4<br /> Read of size 8 at addr ffffff87a2f1acb8 by task kworker/u16:2/153<br /> <br /> Workqueue: events_unbound deferred_probe_work_func<br /> Call trace:<br /> dump_backtrace+0x0/0x33c<br /> show_stack+0x18/0x24<br /> dump_stack_lvl+0x16c/0x1e0<br /> print_address_description+0x84/0x39c<br /> __kasan_report+0x184/0x308<br /> kasan_report+0x50/0x78<br /> __asan_load8+0xc0/0xc4<br /> of_iommu_configure+0xb4/0x4a4<br /> of_dma_configure_id+0x2fc/0x4d4<br /> platform_dma_configure+0x40/0x5c<br /> really_probe+0x1b4/0xb74<br /> driver_probe_device+0x11c/0x228<br /> __device_attach_driver+0x14c/0x304<br /> bus_for_each_drv+0x124/0x1b0<br /> __device_attach+0x25c/0x334<br /> device_initial_probe+0x24/0x34<br /> bus_probe_device+0x78/0x134<br /> deferred_probe_work_func+0x130/0x1a8<br /> process_one_work+0x4c8/0x970<br /> worker_thread+0x5c8/0xaec<br /> kthread+0x1f8/0x220<br /> ret_from_fork+0x10/0x18<br /> <br /> Allocated by task 1:<br /> ____kasan_kmalloc+0xd4/0x114<br /> __kasan_kmalloc+0x10/0x1c<br /> kmem_cache_alloc_trace+0xe4/0x3d4<br /> __iommu_probe_device+0x90/0x394<br /> probe_iommu_group+0x70/0x9c<br /> bus_for_each_dev+0x11c/0x19c<br /> bus_iommu_probe+0xb8/0x7d4<br /> bus_set_iommu+0xcc/0x13c<br /> arm_smmu_bus_init+0x44/0x130 [arm_smmu]<br /> arm_smmu_device_probe+0xb88/0xc54 [arm_smmu]<br /> platform_drv_probe+0xe4/0x13c<br /> really_probe+0x2c8/0xb74<br /> driver_probe_device+0x11c/0x228<br /> device_driver_attach+0xf0/0x16c<br /> __driver_attach+0x80/0x320<br /> bus_for_each_dev+0x11c/0x19c<br /> driver_attach+0x38/0x48<br /> bus_add_driver+0x1dc/0x3a4<br /> driver_register+0x18c/0x244<br /> __platform_driver_register+0x88/0x9c<br /> init_module+0x64/0xff4 [arm_smmu]<br /> do_one_initcall+0x17c/0x2f0<br /> do_init_module+0xe8/0x378<br /> load_module+0x3f80/0x4a40<br /> __se_sys_finit_module+0x1a0/0x1e4<br /> __arm64_sys_finit_module+0x44/0x58<br /> el0_svc_common+0x100/0x264<br /> do_el0_svc+0x38/0xa4<br /> el0_svc+0x20/0x30<br /> el0_sync_handler+0x68/0xac<br /> el0_sync+0x160/0x180<br /> <br /> Freed by task 1:<br /> kasan_set_track+0x4c/0x84<br /> kasan_set_free_info+0x28/0x4c<br /> ____kasan_slab_free+0x120/0x15c<br /> __kasan_slab_free+0x18/0x28<br /> slab_free_freelist_hook+0x204/0x2fc<br /> kfree+0xfc/0x3a4<br /> __iommu_probe_device+0x284/0x394<br /> probe_iommu_group+0x70/0x9c<br /> bus_for_each_dev+0x11c/0x19c<br /> bus_iommu_probe+0xb8/0x7d4<br /> bus_set_iommu+0xcc/0x13c<br /> arm_smmu_bus_init+0x44/0x130 [arm_smmu]<br /> arm_smmu_device_probe+0xb88/0xc54 [arm_smmu]<br /> platform_drv_probe+0xe4/0x13c<br /> really_probe+0x2c8/0xb74<br /> driver_probe_device+0x11c/0x228<br /> device_driver_attach+0xf0/0x16c<br /> __driver_attach+0x80/0x320<br /> bus_for_each_dev+0x11c/0x19c<br /> driver_attach+0x38/0x48<br /> bus_add_driver+0x1dc/0x3a4<br /> driver_register+0x18c/0x244<br /> __platform_driver_register+0x88/0x9c<br /> init_module+0x64/0xff4 [arm_smmu]<br /> do_one_initcall+0x17c/0x2f0<br /> do_init_module+0xe8/0x378<br /> load_module+0x3f80/0x4a40<br /> __se_sys_finit_module+0x1a0/0x1e4<br /> __arm64_sys_finit_module+0x44/0x58<br /> el0_svc_common+0x100/0x264<br /> do_el0_svc+0x38/0xa4<br /> el0_svc+0x20/0x30<br /> el0_sync_handler+0x68/0xac<br /> el0_sync+0x160/0x180<br /> <br /> Fix this by setting dev-&gt;iommu to NULL first and<br /> then freeing dev_iommu structure in dev_iommu_free<br /> function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup<br /> <br /> ax88179_rx_fixup() contains several out-of-bounds accesses that can be<br /> triggered by a malicious (or defective) USB device, in particular:<br /> <br /> - The metadata array (hdr_off..hdr_off+2*pkt_cnt) can be out of bounds,<br /> causing OOB reads and (on big-endian systems) OOB endianness flips.<br /> - A packet can overlap the metadata array, causing a later OOB<br /> endianness flip to corrupt data used by a cloned SKB that has already<br /> been handed off into the network stack.<br /> - A packet SKB can be constructed whose tail is far beyond its end,<br /> causing out-of-bounds heap data to be considered part of the SKB&amp;#39;s<br /> data.<br /> <br /> I have tested that this can be used by a malicious USB device to send a<br /> bogus ICMPv6 Echo Request and receive an ICMPv6 Echo Reply in response<br /> that contains random kernel heap data.<br /> It&amp;#39;s probably also possible to get OOB writes from this on a<br /> little-endian system somehow - maybe by triggering skb_cow() via IP<br /> options processing -, but I haven&amp;#39;t tested that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/proc: task_mmu.c: don&amp;#39;t read mapcount for migration entry<br /> <br /> The syzbot reported the below BUG:<br /> <br /> kernel BUG at include/linux/page-flags.h:785!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 1 PID: 4392 Comm: syz-executor560 Not tainted 5.16.0-rc6-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:PageDoubleMap include/linux/page-flags.h:785 [inline]<br /> RIP: 0010:__page_mapcount+0x2d2/0x350 mm/util.c:744<br /> Call Trace:<br /> page_mapcount include/linux/mm.h:837 [inline]<br /> smaps_account+0x470/0xb10 fs/proc/task_mmu.c:466<br /> smaps_pte_entry fs/proc/task_mmu.c:538 [inline]<br /> smaps_pte_range+0x611/0x1250 fs/proc/task_mmu.c:601<br /> walk_pmd_range mm/pagewalk.c:128 [inline]<br /> walk_pud_range mm/pagewalk.c:205 [inline]<br /> walk_p4d_range mm/pagewalk.c:240 [inline]<br /> walk_pgd_range mm/pagewalk.c:277 [inline]<br /> __walk_page_range+0xe23/0x1ea0 mm/pagewalk.c:379<br /> walk_page_vma+0x277/0x350 mm/pagewalk.c:530<br /> smap_gather_stats.part.0+0x148/0x260 fs/proc/task_mmu.c:768<br /> smap_gather_stats fs/proc/task_mmu.c:741 [inline]<br /> show_smap+0xc6/0x440 fs/proc/task_mmu.c:822<br /> seq_read_iter+0xbb0/0x1240 fs/seq_file.c:272<br /> seq_read+0x3e0/0x5b0 fs/seq_file.c:162<br /> vfs_read+0x1b5/0x600 fs/read_write.c:479<br /> ksys_read+0x12d/0x250 fs/read_write.c:619<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The reproducer was trying to read /proc/$PID/smaps when calling<br /> MADV_FREE at the mean time. MADV_FREE may split THPs if it is called<br /> for partial THP. It may trigger the below race:<br /> <br /> CPU A CPU B<br /> ----- -----<br /> smaps walk: MADV_FREE:<br /> page_mapcount()<br /> PageCompound()<br /> split_huge_page()<br /> page = compound_head(page)<br /> PageDoubleMap(page)<br /> <br /> When calling PageDoubleMap() this page is not a tail page of THP anymore<br /> so the BUG is triggered.<br /> <br /> This could be fixed by elevated refcount of the page before calling<br /> mapcount, but that would prevent it from counting migration entries, and<br /> it seems overkilling because the race just could happen when PMD is<br /> split so all PTE entries of tail pages are actually migration entries,<br /> and smaps_account() does treat migration entries as mapcount == 1 as<br /> Kirill pointed out.<br /> <br /> Add a new parameter for smaps_account() to tell this entry is migration<br /> entry then skip calling page_mapcount(). Don&amp;#39;t skip getting mapcount<br /> for device private entries since they do track references with mapcount.<br /> <br /> Pagemap also has the similar issue although it was not reported. Fixed<br /> it as well.<br /> <br /> [shy828301@gmail.com: v4]<br /> [nathan@kernel.org: avoid unused variable warning in pagemap_pmd_range()]