Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 19 Dec 2018 00:56:42 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc:     Andrew Cooper <andrew.cooper3@citrix.com>,
        YueHaibing <yuehaibing@huawei.com>,
        Juergen Gross <jgross@suse.com>, sstabellini@kernel.org,
        tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com,
        xen-devel@lists.xenproject.org, x86@kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH -next] x86/xen: Fix read buffer overflow
Message-ID: <20181218215642.GL19692@kadam>
References: <20181218081910.18080-1-yuehaibing@huawei.com>
 <7825d772-338a-e39e-eaff-73e666ef5c08@suse.com>
 <2fe8f6b7-b791-e7ea-6484-491e089321d5@huawei.com>
 <08a359b7-1746-8997-4c19-b60a30ccdd63@citrix.com>
 <0de982b7-3402-9321-bd6a-f40de653f6e1@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0de982b7-3402-9321-bd6a-f40de653f6e1@oracle.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Dec 18, 2018 at 12:35:34PM -0500, Boris Ostrovsky wrote:
> On 12/18/18 6:28 AM, Andrew Cooper wrote:
> > On 18/12/2018 10:42, YueHaibing wrote:
> >> On 2018/12/18 16:31, Juergen Gross wrote:
> >>> On 18/12/2018 09:19, YueHaibing wrote:
> >>>> Fix smatch warning:
> >>>>
> >>>> arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error:
> >>>>  buffer overflow 'early_idt_handler_array' 32 <= 32
> >>>>
> >>>> Fixes: 42b3a4cb5609 ("x86/xen: Support early interrupts in xen pv guests")
> >>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> >>>> ---
> >>>>  arch/x86/xen/enlighten_pv.c | 2 +-
> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> >>>> index 2f6787f..81f200d 100644
> >>>> --- a/arch/x86/xen/enlighten_pv.c
> >>>> +++ b/arch/x86/xen/enlighten_pv.c
> >>>> @@ -646,7 +646,7 @@ static bool __ref get_trap_addr(void **addr, unsigned int ist)
> >>>>  
> >>>>  	if (nr == ARRAY_SIZE(trap_array) &&
> >>>>  	    *addr >= (void *)early_idt_handler_array[0] &&
> >>>> -	    *addr < (void *)early_idt_handler_array[NUM_EXCEPTION_VECTORS]) {
> >>>> +	    *addr < (void *)early_idt_handler_array[NUM_EXCEPTION_VECTORS - 1]) {
> >>>>  		nr = (*addr - (void *)early_idt_handler_array[0]) /
> >>>>  		     EARLY_IDT_HANDLER_SIZE;
> >>>>  		*addr = (void *)xen_early_idt_handler_array[nr];
> >>>>
> >>> No, this patch is wrong.
> >>>
> >>> early_idt_handler_array is a 2-dimensional array:
> >>>
> >>> const char
> >>> early_idt_handler_array[NUM_EXCEPTION_VECTORS][EARLY_IDT_HANDLER_SIZE];
> >>>
> >>> So above code doesn't do an out of bounds array access, but checks for
> >>> *addr being in the array or outside of it (note the "<" used for the
> >>> test).
> >> Thank you for your explanation.
> > This looks like a smatch bug.? I'd feed it back upstream.
> 
> +Dan
> 

Yep.  Thanks for the bug report.  Let me test my fix and push it later
this week.

Btw, it might help readability slightly if we made it more clear we were
doing pointer math:

		*addr >= (void *)&early_idt_handler_array[0] &&
		*addr < (void *)&early_idt_handler_array[NUM_EXCEPTION_VECTORS]) {
			nr = (*addr - (void *)&early_idt_handler_array[0]) /

Regardless, this is definitely a bug in Smatch and I will push a fix.

regards,
dan carpenter