Subject: Re: [PATCH v2] block: fix possible NULL dereference
To: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
References: <1459521258-18534-1-git-send-email-sudipm.mukherjee@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
        Johannes Thumshirn <jthumshirn@suse.de>
From: Jens Axboe <axboe@kernel.dk>
Message-ID: <56FE87DF.3000603@kernel.dk>
Date: Fri, 1 Apr 2016 08:38:23 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <1459521258-18534-1-git-send-email-sudipm.mukherjee@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 739
Lines: 20

On 04/01/2016 08:34 AM, Sudip Mukherjee wrote:
> We were checking for iter to be NULL after dereferencing it. There is
> actually no need to check for iter to be NULL as all the callers of
> blk_rq_map_user_iov() does call it with a valid pointer to
> struct iov_iter.
> But as iter->count can be NULL so the assignment to copy is being done
> after checking for it.
>
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
> ---
>
> v2: removed the check for iter
> v1: moved the assignment to copy after check for iter and iter->count

Your subject is wrong (there's no NULL deref). Ditto for the commit 
message - it can be zero, not NULL. The latter would imply a memory 
address, but it's just an integer.

-- 
Jens Axboe