| Message ID | 20241016111458.846228-2-kirill.shutemov@linux.intel.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere, archived |
| Headers | show |
| Series | x86: Reduce code duplication on page table initialization | expand |
On Wed, Oct 16, 2024 at 02:14:55PM +0300, Kirill A. Shutemov wrote: > Calculation of 'next' virtual address doesn't protect against wrapping > to zero. It can result in page table corruption and hang. The > problematic case is possible if user sets high x86_mapping_info::offset. > > The wrapping to zero only occurs if the top PGD entry is accessed. > There are no such users in the upstream. Only hibernate_64.c uses > x86_mapping_info::offset, and it operates on the direct mapping range, > which is not the top PGD entry. > > Replace manual 'next' calculation with p?d_addr_end() which handles > wrapping correctly. So this is a fix for a theoretical issue as it cannot happen currently? Can we call that out in the commit message so that the stable AI doesn't pick it up? And which commit is it fixing? aece27851d44 ("x86, 64bit, mm: Add generic kernel/ident mapping helper") perhaps? Always add Fixes: tags when a patch is fixing something - you know that. Thx.
On Wed, Oct 30, 2024 at 12:47:12PM +0100, Borislav Petkov wrote: > On Wed, Oct 16, 2024 at 02:14:55PM +0300, Kirill A. Shutemov wrote: > > Calculation of 'next' virtual address doesn't protect against wrapping > > to zero. It can result in page table corruption and hang. The > > problematic case is possible if user sets high x86_mapping_info::offset. > > > > The wrapping to zero only occurs if the top PGD entry is accessed. > > There are no such users in the upstream. Only hibernate_64.c uses > > x86_mapping_info::offset, and it operates on the direct mapping range, > > which is not the top PGD entry. > > > > Replace manual 'next' calculation with p?d_addr_end() which handles > > wrapping correctly. > > So this is a fix for a theoretical issue as it cannot happen currently? Right. > Can we call that out in the commit message so that the stable AI doesn't pick > it up? Do we have magic words for that? I tried to express that in the second paragraph: "no such users in the upstream". > And which commit is it fixing? > > aece27851d44 ("x86, 64bit, mm: Add generic kernel/ident mapping helper") > perhaps? This one is closer: e4630fdd4763 ("x86/power/64: Always create temporary identity mapping correctly") It adds x86_mapping_info::offset.
On Thu, Oct 31, 2024 at 12:11:52PM +0200, Kirill A. Shutemov wrote: > Do we have magic words for that? No clue. > I tried to express that in the second paragraph: "no such users in the > upstream". Right, so perhaps better to spell it out explicitly: "Backporter's note: This fixes a theoretical issue only and there's no need to backport it to stable." at the end of the commit message. > > And which commit is it fixing? > > > > aece27851d44 ("x86, 64bit, mm: Add generic kernel/ident mapping helper") > > perhaps? > > This one is closer: > > e4630fdd4763 ("x86/power/64: Always create temporary identity mapping correctly") > > It adds x86_mapping_info::offset. But aece27851d44 has the faulty check...
On Thu, Oct 31, 2024 at 02:59:16PM +0100, Borislav Petkov wrote: > On Thu, Oct 31, 2024 at 12:11:52PM +0200, Kirill A. Shutemov wrote: > > Do we have magic words for that? > > No clue. > > > I tried to express that in the second paragraph: "no such users in the > > upstream". > > Right, so perhaps better to spell it out explicitly: > > "Backporter's note: > > This fixes a theoretical issue only and there's no need to backport it to > stable." > > at the end of the commit message. Okay. > > > > And which commit is it fixing? > > > > > > aece27851d44 ("x86, 64bit, mm: Add generic kernel/ident mapping helper") > > > perhaps? > > > > This one is closer: > > > > e4630fdd4763 ("x86/power/64: Always create temporary identity mapping correctly") > > > > It adds x86_mapping_info::offset. > > But aece27851d44 has the faulty check... It cannot be triggered without 'offset'. I'll put both.
diff --git a/arch/x86/mm/ident_map.c b/arch/x86/mm/ident_map.c index 437e96fb4977..5872f3ee863c 100644 --- a/arch/x86/mm/ident_map.c +++ b/arch/x86/mm/ident_map.c @@ -101,9 +101,7 @@ static int ident_pud_init(struct x86_mapping_info *info, pud_t *pud_page, pmd_t *pmd; bool use_gbpage; - next = (addr & PUD_MASK) + PUD_SIZE; - if (next > end) - next = end; + next = pud_addr_end(addr, end); /* if this is already a gbpage, this portion is already mapped */ if (pud_leaf(*pud)) @@ -154,10 +152,7 @@ static int ident_p4d_init(struct x86_mapping_info *info, p4d_t *p4d_page, p4d_t *p4d = p4d_page + p4d_index(addr); pud_t *pud; - next = (addr & P4D_MASK) + P4D_SIZE; - if (next > end) - next = end; - + next = p4d_addr_end(addr, end); if (p4d_present(*p4d)) { pud = pud_offset(p4d, 0); result = ident_pud_init(info, pud, addr, next); @@ -199,10 +194,7 @@ int kernel_ident_mapping_init(struct x86_mapping_info *info, pgd_t *pgd_page, pgd_t *pgd = pgd_page + pgd_index(addr); p4d_t *p4d; - next = (addr & PGDIR_MASK) + PGDIR_SIZE; - if (next > end) - next = end; - + next = pgd_addr_end(addr, end); if (pgd_present(*pgd)) { p4d = p4d_offset(pgd, 0); result = ident_p4d_init(info, p4d, addr, next);