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]
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

Powered by blists - more mailing lists