linux-ext4 - Kernel panic in ext4_ext_drop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <c5d90b6ba6826fb0d6ab245befdfc405@codeaurora.org>
Date:   Mon, 11 Sep 2017 10:40:23 +0530
From:   ankijain@...eaurora.org
To:     linux-ext4@...r.kernel.org
Subject: Kernel panic in ext4_ext_drop_refs

Hi

We are facing  issue use after free/un-initialized in ext4 delayed 
allocation path for write request to a file.

Details:
machine arm64
kernel : 4.9.40

Issue detail:
Panic is occurred while accessing uninitialized/free path variable 
inside ext4_ext_drop_refs()
ext4_ext_drop_refs(
     path = 0xFFFFFFC757A85C00 -> (
       p_block = 0x6B6B6B6B6B6B6B6B,
       p_depth = 0x6B6B,
       p_maxdepth = 0x6B6B,
       p_ext = 0x6B6B6B6B6B6B6B6B,
       p_idx = 0x6B6B6B6B6B6B6B6B,
       p_hdr = 0x6B6B6B6B6B6B6B6B,
       p_bh = 0x6B6B6B6B6B6B6B6B))

This path variable is representing extent path from root extent to leaf 
of requested logical block of file.
we have allocated memory for this path variable inside 
ext4_find_extent() locally and trying to free it inside 
ext4_ext_drop_refs().
http://elixir.free-electrons.com/linux/v4.9.40/source/fs/ext4/extents.c#L894 
   ----> allocation happen without any error.
http://elixir.free-electrons.com/linux/v4.9.40/source/fs/ext4/extents.c#L4620 
  ----> trying to free previously allocated memory.

Device is running in low memory condition.
	PAGES        TOTAL      PERCENTAGE
  FREE     6720      26.2 MB    0% of TOTAL MEM

could anyone help us to find, in which scenario this path variable can 
get free/uninitialized before ext4_ext_drop_refs()?

Unable to handle kernel paging request at virtual address 6b6b6b6b6b6bcb
<1>[ 4072.876804] pgd = ffffffc7b6c91000
<1>[ 4072.885604] [6b6b6b6b6b6bcb] *pgd=0000000000000000
  __brelse+0x18/0x50
  ext4_ext_drop_refs+0x3c/0x5c
  ext4_ext_map_blocks+0x418/0x1b34
  ext4_da_get_block_prep+0x200/0x4fc
  __block_write_begin_int+0x160/0x630
  __block_write_begin+0x3c/0x48fs stack.
  ext4_da_write_begin+0x17c/0x574block layer issue (from ritesh)
  generic_perform_write+0xc8/0x1d4uid issue
  __generic_file_write_iter+0x15c/0x1a8
  ext4_file_write_iter+0x108/0x354
  new_sync_write+0xd8/0x124
  vfs_write+0x15c/0x1d0
  SyS_pwrite64+0xb0/0xc8
  __sys_trace_return+0x0/0x4