linux-kernel - Regression in squashfs mount option handling in v5.4

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>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191130181548.GA28459@gentoo-tp.home>
Date:   Sat, 30 Nov 2019 19:15:48 +0100
From:   Jeremi Piotrowski <jeremi.piotrowski@...il.com>
To:     linux-kernel@...r.kernel.org
Subject: Regression in squashfs mount option handling in v5.4

Hi,

I'm working on an embedded project which uses 'rauc' as an updater. rauc mounts
a squashfs image using

  mount -t squashfs -o ro,loop,sizelimit=xxx squashfs.img /mnt

On my system mount is busybox, and busybox does not know the sizelimit
parameter, so it simply passes it on to the mount syscall. The syscall
arguments end up being:

  mount("/dev/loop0", "dir", "squashfs", MS_RDONLY|MS_SILENT, "sizelimit=xxx")

Until kernel 5.4 this worked, since 5.4 this returns EINVAL and dmesg contains
the line "squashfs: Unknown parameter 'sizelimit'". I believe this has to do
with the conversion of squashfs to the new mount api. 

This is an unfortunate regression, and it does not seem like this can be simply
reverted. What is the suggested course of action?

Please cc me on replies, I'm not subscribed to the list.

Thanks,
Jeremi