From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Wed, 22 Apr 2015 13:15:07 +0200 Subject: [U-Boot] [PATCH] cmd_sf: Fix problem with "sf update" and unaligned length In-Reply-To: References: <1420810762-10712-1-git-send-email-sr@denx.de> <20150112071719.055CB38005C@gemini.denx.de> <54B37759.7040801@denx.de> <20150112211034.AC27C384DF9@gemini.denx.de> <54B4B595.5000703@denx.de> Message-ID: <553782BB.6050901@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 22.04.2015 13:11, Jagan Teki wrote: >> On 12.01.2015 22:10, Wolfgang Denk wrote: >>>>> >>>>> Should we add a memset(buf, 0, sizeof(buf)) before the memcpy() to >>>>> prevent information from earlier activities to leak? >>>> >>>> >>>> "buf" points to the new data to be written into the flash. We're >>>> overwriting the first "len" bytes of "cmp_buf" with this data. >>> >>> >>> Oh, sorry for the mixup. Then cmp_buf should be cleared (or at elast >>> the remaining, unused part). >> >> >> No. cmp_buf contains the original data from the flash. And only the >> beginning of this buffer is overwritten with the new data from "buf". So, >> the result of the memcpy() is that "cmp_buf" contains the data that should >> be written into the flash. Its a combination of the "original data" and the >> "new data". >> >>>> I don't see why we should erase anything there. Perhaps I'm missing >>>> something though. >>> >>> >>> You are leaking data. This could contain "interesting" information; >>> see the OpenSSL ?Heartbleed? vulnerability for a (nasty) example what >>> information leakage can do. >> >> >> There is nothing leaking here. When anything would be zeroed out, the >> resulting buffer would not be the one that should be used. > > I think this thread link got stopped any further update on this. I would have thought that this patch had been applied some time ago. If not, then please do. Thanks, Stefan