(original) (raw)
Hi folks,
It’s easy to see how memcpy (and other mem\* functions) can cause out-of-bounds reads/writes, such as in this simplified reproducer for a real case we’ve seen:
�� #include
�� struct S {
����� int x;
����� int xx;
����� int y\[\];
�� };
�� char dst\[100\];
��
���int main(void) {
����� struct S src = {0};
����� src.x = 9999;
����� src.xx = 8888;
����� memcpy(dst, &src, sizeof(struct S) + 1);
�� }
Here, the size argument to memcpy is clearly just wrong.� But consider that when FAMs are in play (as is hinted at here), designers can get confused and use the wrong size value – probably there are plenty of other circumstances where such coding errors are easy to make, and not easy to spot during review.� At present, CFE can’t catch this during compilation (unless I’ve missed something).� It can be caught by the static analysis check “alpha.unix.cstring.OutOfBounds” – but that’s rather late, rather costly, and rather noisy (which I’m sure is why it’s an alpha check and not a core check).� This seems like something that could be caught and flagged by either a diagnostic or a tidy-check…�� Is that reasonable? �If not, why not?
Regards,
Chris Hamilton
Compiler Developer
BNEW DNEW 4G5G BI BBI 10
Mobile: +1-512-955-0143
“Without inclusion, diversity is only a statistic.” �-- B�rje Ekholm, CEO of Ericsson
Ericsson
1703 W. 5th Street Suite 600
78703,Austin, Texas
United States
Our commitment to Technology for Good and Diversity and Inclusion contributes to positive change.
Follow us on: Facebook LinkedIn Twitter
Legal entity:ERICSSON AB registration number 556056-6258, registered office in Stockholm.
This communication is confidential. Our email terms: www.ericsson.com/en/legal/privacy/email-disclaimer