In the Linux kernel, the following vulnerability has been resolved:
hugetlbfs: don't delete error page from pagecache
This change is very similar to the change that was made for shmem [1], and
it so
In the Linux kernel, the following vulnerability has been resolved:
mm: use aligned address in clear_gigantic_page()
In current kernel, hugetlb_no_page() calls folio_zero_user() with the
fault addre
In the Linux kernel, the following vulnerability has been resolved:
mm/memfd: fix information leak in hugetlb folios
When allocating hugetlb folios for memfd, three initialization steps are
missing:
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix memfd_pin_folios free_huge_pages leak
memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages
i
In the Linux kernel, the following vulnerability has been resolved:
mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pages
The h->*_huge_pages counters are protected by the hugetlb_loc
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list
In shrink_folio_list(), the hwpoisoned folio may be large foli
In the Linux kernel, the following vulnerability has been resolved:
mm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_buddy()
In split_large_buddy(), we might call
In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: fix NULL pointer deference when splitting folio
Commit c010d47f107f ("mm: thp: split huge page to any lower order
In the Linux kernel, the following vulnerability has been resolved:
mm/mempool: fix poisoning order>0 pages with HIGHMEM
The kernel test has reported:
BUG: unable to handle page fault for address
In the Linux kernel, the following vulnerability has been resolved:
mm/gup: fix memfd_pin_folios alloc race panic
If memfd_pin_folios tries to create a hugetlb page, but someone else
already did, th
In the Linux kernel, the following vulnerability has been resolved:
mm: use aligned address in copy_user_gigantic_page()
In current kernel, hugetlb_wp() calls copy_user_large_folio() with the
fault
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: avoid corrupting page->mapping in hugetlb_mcopy_atomic_pte
In MCOPY_ATOMIC_CONTINUE case with a non-shared VMA, pages
In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory
When I did memory failure tests, below panic occurs
In the Linux kernel, the following vulnerability has been resolved:
mm/userfaultfd: fix hugetlb fault mutex hash calculation
In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the
p
In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: drop beyond-EOF folios with the right number of refs
When an after-split folio is large and needs to be dropped du
In the Linux kernel, the following vulnerability has been resolved:
s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP
As reported by Luiz Capitulino enabling HVO on s390 leads to reproducible
crashes
In the Linux kernel, the following vulnerability has been resolved:
module: fix [e_shstrndx].sh_size=0 OOB access
It is trivial to craft a module to trigger OOB access in this line:
if (info->secs
In the Linux kernel, the following vulnerability has been resolved:
x86/sgx: Prevent attempts to reclaim poisoned pages
TL;DR: SGX page reclaim touches the page to copy its contents to
secondary sto
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix data corruption after failed write
When buffered write fails to copy data into underlying page cache page,
ocfs2_write_
In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: don't unpoison huge_zero_folio
When I did memory failure tests recently, below panic occurs:
kernel BUG at inclu
Page 1+ Next →