linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hao Ge <hao.ge@linux.dev>
To: Suren Baghdasaryan <surenb@google.com>
Cc: kent.overstreet@linux.dev, akpm@linux-foundation.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Hao Ge <gehao@kylinos.cn>
Subject: Re: [PATCH v2] mm/alloc_tag: fix vm_module_tags_populate's KASAN poisoning logic
Date: Wed, 4 Dec 2024 23:07:35 +0800	[thread overview]
Message-ID: <e5d6cb44-9a86-ee94-9210-d56acee483c4@linux.dev> (raw)
In-Reply-To: <CAJuCfpF5Yo3Bz1OUy=rfd5-0DRZsWSRaekR3Y-f5TRatdXWkVQ@mail.gmail.com>

Hi Suren


Thank you for your review.


On 12/4/24 22:39, Suren Baghdasaryan wrote:
> On Wed, Dec 4, 2024 at 12:35 AM Hao Ge <hao.ge@linux.dev> wrote:
>> From: Hao Ge <gehao@kylinos.cn>
>>
>> After merge commit 233e89322cbe ("alloc_tag:
>> fix module allocation tags populated area calculation"),
>> We still encountered a KASAN bug.
>>
>> This is because we have only actually performed
>> page allocation and address mapping here.
>> we need to unpoisoned portions of underlying memory.
>>
>> Because we have a change in the size here,we need to
>> re-annotate poisoned and unpoisoned portions of underlying memory
>> according to the new size.
>>
>> Here is the log for KASAN:
>>
>> [    5.041171][    T1] ==================================================================
>> [    5.042047][    T1] BUG: KASAN: vmalloc-out-of-bounds in move_module+0x2c0/0x708
>> [    5.042723][    T1] Write of size 240 at addr ffff80007e510000 by task systemd/1
>> [    5.043412][    T1]
>> [    5.043523][   T72] input: QEMU QEMU USB Tablet as /devices/pci0000:00/0000:00:01.1/0000:02:001
>> [    5.043614][    T1] CPU: 0 UID: 0 PID: 1 Comm: systemd Not tainted 6.13.0-rc1+ #28
>> [    5.045560][    T1] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
>> [    5.046328][    T1] Call trace:
>> [    5.046670][    T1]  show_stack+0x20/0x38 (C)
>> [    5.047127][    T1]  dump_stack_lvl+0x80/0xf8
>> [    5.047533][    T1]  print_address_description.constprop.0+0x58/0x358
>> [    5.048092][   T72] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 Mouse [QEMU 0
>> [    5.048126][    T1]  print_report+0xb0/0x280
>> [    5.049682][    T1]  kasan_report+0xb8/0x108
>> [    5.050170][    T1]  kasan_check_range+0xe8/0x190
>> [    5.050685][    T1]  memcpy+0x58/0xa0
>> [    5.051135][    T1]  move_module+0x2c0/0x708
>> [    5.051586][    T1]  layout_and_allocate.constprop.0+0x308/0x5b8
>> [    5.052219][    T1]  load_module+0x134/0x16c8
>> [    5.052671][    T1]  init_module_from_file+0xdc/0x138
>> [    5.053193][    T1]  idempotent_init_module+0x344/0x600
>> [    5.053742][    T1]  __arm64_sys_finit_module+0xbc/0x150
>> [    5.054289][    T1]  invoke_syscall+0xd4/0x258
>> [    5.054749][    T1]  el0_svc_common.constprop.0+0xb4/0x240
>> [    5.055319][    T1]  do_el0_svc+0x48/0x68
>> [    5.055743][    T1]  el0_svc+0x40/0xe0
>> [    5.056142][    T1]  el0t_64_sync_handler+0x10c/0x138
>> [    5.056658][    T1]  el0t_64_sync+0x1ac/0x1b0
>>
>> Fixes: 233e89322cbe ("alloc_tag: fix module allocation tags populated area calculation")
>> Signed-off-by: Hao Ge <gehao@kylinos.cn>
> Thanks for the fix!
>
>> ---
>> v2: Add comments to kasan_unpoison_vmalloc like other places.
>>
>> commit 233e89322cbe ("alloc_tag: fix module allocation
>> tags populated area calculation") is currently in the
>> mm-hotfixes-unstable branch, so this patch is
>> developed based on the mm-hotfixes-unstable branch.
>> ---
>>   lib/alloc_tag.c | 13 +++++++++++++
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
>> index 4ee6caa6d2da..f885b3f3af0e 100644
>> --- a/lib/alloc_tag.c
>> +++ b/lib/alloc_tag.c
>> @@ -421,7 +421,20 @@ static int vm_module_tags_populate(void)
>>                                  __free_page(next_page[i]);
>>                          return -ENOMEM;
>>                  }
>> +
>> +               kasan_poison_vmalloc((void *)module_tags.start_addr,
>> +                                    vm_module_tags->nr_pages << PAGE_SHIFT);
>> +
>>                  vm_module_tags->nr_pages += nr;
>> +
>> +               /*
>> +                * Mark the pages as accessible, now that they are mapped.
>> +                * With hardware tag-based KASAN, marking is skipped for
>> +                * non-VM_ALLOC mappings, see __kasan_unpoison_vmalloc().
>> +                */
>> +               kasan_unpoison_vmalloc((void *)module_tags.start_addr,
>> +                                      vm_module_tags->nr_pages << PAGE_SHIFT,
>> +                                      KASAN_VMALLOC_PROT_NORMAL);
> Instead of poisoning [module_tags.start_addr,
> vm_module_tags->nr_pages], incrementing vm_module_tags->nr_pages and
> the unpoisoning [module_tags.start_addr, vm_module_tags->nr_pages]
> could we simply poisons the additional area like this:
>
>                  kasan_unpoison_vmalloc((void *)module_tags.start_addr +
>                                         (vm_module_tags->nr_pages << PAGE_SHIFT),
>                                         nr << PAGE_SHIFT,
>                                         KASAN_VMALLOC_PROT_NORMAL);
>                 vm_module_tags->nr_pages += nr;
> ?


I had considered making such modifications earlier.

But considering the following situation,

A module tags spans across the regions of [module_tags.start_addr, 
vm_module_tags->nr_pages] and [module_tags.start_addr + 
vm_module_tags->nr_pages, ...].

It may result in false positives for out-of-bounds errors.


>>          }
>>
>>          return 0;
>> --
>> 2.25.1
>>


  reply	other threads:[~2024-12-04 15:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-04  7:52 [PATCH] " Hao Ge
2024-12-04  8:34 ` [PATCH v2] " Hao Ge
2024-12-04 14:39   ` Suren Baghdasaryan
2024-12-04 15:07     ` Hao Ge [this message]
2024-12-04 19:33       ` Suren Baghdasaryan
2024-12-05  2:14         ` Hao Ge
2024-12-05  3:20           ` Hao Ge
2024-12-05 14:48             ` Suren Baghdasaryan
2024-12-05 15:34               ` Hao Ge
2024-12-05 16:25                 ` Hao Ge
2024-12-05 17:05                   ` [PATCH v3] " Hao Ge
2024-12-06 19:03                     ` Suren Baghdasaryan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e5d6cb44-9a86-ee94-9210-d56acee483c4@linux.dev \
    --to=hao.ge@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=gehao@kylinos.cn \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=surenb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox