linux-kernel - Re: Fwd: New Defects reported by Coverity Scan for Linux

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:	Sun, 13 Apr 2014 00:41:45 +0300
From:	Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Fwd: New Defects reported by Coverity Scan for Linux

On Sat, Apr 12, 2014 at 07:29:29AM -0600, Bjorn Helgaas wrote:
> FYI, looks like these were added by a4dff76924fe ("x86/gpu: Add Intel
> graphics stolen memory quirk for gen2 platforms").

Some of the affected gen2 platforms do support up to 2GB of RAM which
means that if the sign extension were to happen they could hit this.
However I believe all gen2 platforms are 32bit which AFAIK makes size_t 
32 bits. So looks like we can't hit this in practice..

But if someone were to change the return type to 64bits we'd
be in real danger, so I guess it would be better to fix the bug
anyway.

-#define KB(x)  ((x) * 1024)
+#define KB(x)  ((x) * 1024U)
should be sufficient to eliminate the problem. If someone wants me to
put that into a real patch and send it out let me know.

> 
> 
> ---------- Forwarded message ----------
> From:  <scan-admin@...erity.com>
> Date: Sat, Apr 12, 2014 at 1:24 AM
> Subject: New Defects reported by Coverity Scan for Linux
> To:
> 
> ...
> 
> ** CID 1201423:  Unintended sign extension  (SIGN_EXTENSION)
> /arch/x86/kernel/early-quirks.c: 290 in i830_mem_size()
> 
> ** CID 1201424:  Unintended sign extension  (SIGN_EXTENSION)
> /arch/x86/kernel/early-quirks.c: 295 in i85x_mem_size()
> 
> ...
> ________________________________________________________________________________________________________
> *** CID 1201423:  Unintended sign extension  (SIGN_EXTENSION)
> /arch/x86/kernel/early-quirks.c: 290 in i830_mem_size()
> 284
> 285             return MB(1);
> 286     }
> 287
> 288     static size_t __init i830_mem_size(void)
> 289     {
> >>>     CID 1201423:  Unintended sign extension  (SIGN_EXTENSION)
> >>>     Suspicious implicit sign extension: "read_pci_config_byte(0, 0, 0, 99)" with type "unsigned char" (8 bits, unsigned) is promoted in "read_pci_config_byte(0, 0, 0, 99) * 33554432" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned).  If "read_pci_config_byte(0, 0, 0, 99) * 33554432" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
> 290             return read_pci_config_byte(0, 0, 0, I830_DRB3) * MB(32);
> 291     }
> 292
> 293     static size_t __init i85x_mem_size(void)
> 294     {
> 295             return read_pci_config_byte(0, 0, 1, I85X_DRB3) * MB(32);
> 
> ________________________________________________________________________________________________________
> *** CID 1201424:  Unintended sign extension  (SIGN_EXTENSION)
> /arch/x86/kernel/early-quirks.c: 295 in i85x_mem_size()
> 289     {
> 290             return read_pci_config_byte(0, 0, 0, I830_DRB3) * MB(32);
> 291     }
> 292
> 293     static size_t __init i85x_mem_size(void)
> 294     {
> >>>     CID 1201424:  Unintended sign extension  (SIGN_EXTENSION)
> >>>     Suspicious implicit sign extension: "read_pci_config_byte(0, 0, 1, 67)" with type "unsigned char" (8 bits, unsigned) is promoted in "read_pci_config_byte(0, 0, 1, 67) * 33554432" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned).  If "read_pci_config_byte(0, 0, 1, 67) * 33554432" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
> 295             return read_pci_config_byte(0, 0, 1, I85X_DRB3) * MB(32);
> 296     }
> 297
> 298     /*
> 299      * On 830/845/85x the stolen memory base isn't available in any
> 300      * register. We need to calculate it as TOM-TSEG_SIZE-stolen_size.

-- 
Ville Syrjälä
Intel OTC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/