Re: [PATCH v3 8/9] initramfs: fix hardlink hash leak without TRAILER

[David Disseldorp <ddiss@suse.de>]

On Thu,  7 Nov 2024 11:17:27 +1100, David Disseldorp wrote:

> Covered in Documentation/driver-api/early-userspace/buffer-format.rst ,
> initramfs archives can carry an optional "TRAILER!!!" entry which serves
> as a boundary for collecting and associating hardlinks with matching
> inode and major / minor device numbers.
> 
> Although optional, if hardlinks are found in an archive without a
> subsequent "TRAILER!!!" entry then the hardlink state hash table is
> leaked

One further leak is possible if extraction ends prior to fput(wfile)
in CopyFile state, e.g. due to lack of data:

  nilchar="\0"
  data="123456789ABCDEF"
  magic="070701"
  ino=1
  mode=$(( 0100777 ))
  uid=0
  gid=0
  nlink=1
  mtime=1
  filesize=$(( ${#data} + 20 ))   # too much
  devmajor=0
  devminor=1
  rdevmajor=0
  rdevminor=0
  csum=0
  fname="initramfs_test_archive_overrun"
  namelen=$(( ${#fname} + 1 ))    # plus one to account for terminator
  
  printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \
         $magic $ino $mode $uid $gid $nlink $mtime $filesize \
         $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname

  termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) ))
  printf "%.s${nilchar}" $(seq 1 $termpadlen)
  # $filesize reaches 20 bytes beyond end of data
  printf "%s" "$data"

bash data_repro.sh|gzip >> initramfs

unreferenced object 0xffff8fdb0192e000 (size 176):
  comm "kworker/u8:0", pid 11, jiffies 4294892503
  hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 00 00 00 00 1e 80 5d 00  ..............].
    80 7d a1 a7 ff ff ff ff 10 b1 2f 02 db 8f ff ff  .}......../.....
  backtrace (crc 807bd733):
    [<00000000e68e8b32>] kmem_cache_alloc_noprof+0x11e/0x260
    [<00000000a6f24fcd>] alloc_empty_file+0x45/0x120
    [<00000000130beec8>] path_openat+0x2f/0xf30
    [<0000000024613ad7>] do_filp_open+0xa7/0x110
    [<000000005f4f0158>] file_open_name+0x118/0x180
    [<0000000003ed573f>] filp_open+0x27/0x50
    [<0000000091ec9e44>] do_name+0xc4/0x2b0
    [<000000008e084ec8>] write_buffer+0x22/0x40
    [<000000002ea2ff4b>] flush_buffer+0x2f/0x90
    [<000000009085f8b5>] gunzip+0x25a/0x310
    [<000000000c1c83c3>] unpack_to_rootfs+0x176/0x2a0
    [<00000000c966fda5>] do_populate_rootfs+0x6a/0x180
    [<0000000051fb877d>] async_run_entry_fn+0x31/0x120
    [<00000000a3ee305f>] process_scheduled_works+0xbe/0x310
    [<0000000083c835bb>] worker_thread+0x100/0x240
    [<000000006ea2f0b3>] kthread+0xc8/0x100

Not sure whether others are interested in seeing these kinds of
leak-on-malformed-archive bugs fixed, but I'll send through a v4 with a
fix + unit test for it.