linux-kernel - [PATCH] nvmet: fix mar and mor off-by-one errors

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 6 Sep 2022 07:36:06 +0000
From:   Dennis Maisenbacher <dennis.maisenbacher@....com>
To:     Christoph Hellwig <hch@....de>
CC:     "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
        Niklas Cassel <Niklas.Cassel@....com>,
        Sagi Grimberg <sagi@...mberg.me>,
        Chaitanya Kulkarni <kch@...dia.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: [PATCH] nvmet: fix mar and mor off-by-one errors

>> Cast the unsigned int values that are returned by bdev_max_open_zones and
>> bdev_max_active_zones into u32 vales which need to be decremented as the
>> returned values of the block layer helpers are not 0's based.
>> The cast to u32 is necessary because the size of unsigned int is
>> architecture dependent and a 0 reported by the block layer helpers
>> indicates no limit, thus it needs to be converted to 0xffffffff which
>> happens by underflowing the u32.
>
>unsigned int (in Linux, not the C standard) is not architecture
>dependent but always a 32-bit unsigned integer type.

Thanks for clarifying!

>But I'd much rather see an explicit check for 0 and conversion to
>0xffffffff anyway.  Yes, unsigned integer underflow is well defined,
>but having the explicit check explains much better to the read that it
>is intentional.
>
>Can you also add a Fixes tag, please?

Sure, makes sense. I will address your comments in v2.

Dennis