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.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: Kai Huang <kai.huang@intel.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
---
arch/x86/mm/ident_map.c | 14 +++-----------
1 file changed, 3 insertions(+), 11 deletions(-)
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);
--
2.45.2On 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.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
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.
--
Kiryl Shutsemau / Kirill A. Shutemov
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...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
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.
--
Kiryl Shutsemau / Kirill A. Shutemov
© 2016 - 2024 Red Hat, Inc.