linux-kernel - Re: [PATCH] RDS: IB: ensure an initialized ret is printed in pr

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

Date:   Fri, 07 Apr 2017 06:10:12 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     colin.king@...onical.com
Cc:     santosh.shilimkar@...cle.com, netdev@...r.kernel.org,
        linux-rdma@...r.kernel.org, rds-devel@....oracle.com,
        kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] RDS: IB: ensure an initialized ret is printed in
 pr_warn message

From: Colin King <colin.king@...onical.com>
Date: Fri,  7 Apr 2017 08:57:23 +0100

> From: Colin Ian King <colin.king@...onical.com>
> 
> There is a path where ibmr is null and ret has not been initialized
> and hence a pr_warn message is printing an uninitialized value in
> ret.  Fix this by initializing ret to zero.
> 
> Detected by CoverityScan, CID#1357946 ("Uninitialized scalar variable")
> 
> Signed-off-by: Colin Ian King <colin.king@...onical.com>

These are exactly the kinds of CoverityScan fixes I really do not want
to see.

Initializing ret to zero is not going to fix the problem.

This function gets error pointers back from the functions that are
used to obtain the ibmr pointer.  Therefore if there is a problem
ibmr won't be NULL, it will be an error pointer.

Therefore, the real problem is that the code isn't checking if
ibmr encodes error value.