Error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter

[FAMILIAR-project]

rawtuxdata.query("UBSAN_NULL == 'y' & IPV6 != 'm' & FORTIFY_SOURCE == 'y' & IPV6 != 'y' & INFINIBAND_ADDR_TRANS == 'y' & UBSAN_SANITIZE_ALL == 'y' & GENERIC_ALLOCATOR != 'n' & WANXL_BUILD_FIRMWARE != 'y' & AIC7XXX_BUILD_FIRMWARE != 'y' & AIC79XX_BUILD_FIRMWARE != 'y'")['cid'].values

There seems to be a problem between FORTIFY_SOURCE and IPV6 (as well as UBSAN_NULL and UBSAN_ALIGNMENT)

The full messages are there:
https://gist.github.com/FAMILIAR-project/9b36437b6da01a912807ee4c854a0c2b

and basically a pattern occurs:
./include/linux/string.h:305:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter __read_overflow2();

I'm investigating qualitatively now, but I can already say the failure has hurt many users:
jurobystricky/Netgear-A6210#81
since the default configuration now comprises FORTIFY_SOURCE (a security option).

also reported here:
lwfinger/rtl8188eu#251
lwfinger/rtl8188eu#112
in similar context

interesting discussion:
Thanks to CONFIG_FORTIFY_SOURCE, the compiler refused to compile this buggy code. See https://outflux.net/blog/archives/2017/09/05/security-things-in-linux-v4-13/ for details why this issue hasn't been noticed before kernel 4.13.
genodeftest/Netgear-A6210@dc7e9b8

[FAMILIAR-project]

The compiler verification (thanks to FORTIFY_SOURCE) can explain why calls to memcpy fail:
https://elixir.bootlin.com/linux/v4.13.3/source/drivers/infiniband/core/roce_gid_mgmt.c#L554

FORTIFY_SOURCE: Harden common str/mem functions against buffer overflows
Detect overflows of buffers in common string and memory functions where the compiler can determine and validate the buffer sizes.

UBSAN_NULL: Enable checking of null pointers
This option enables detection of memory accesses via a null pointer.

UBSAN_ALIGNMENT: Enable checking of pointers alignment found in lib/Kconfig.ubsan
This option enables detection of unaligned memory accesses. Enabling this option on architectures that support unaligned accesses may produce a lot of false positives.

When UBSAN_ALIGNMENT == 'n' & UBSAN_NULL == 'n' there is no verification, and so no compilation failures.

What is still unclear is why IPV6 is involved in failures...

rawtuxdata.query("(UBSAN_ALIGNMENT != 'n' | UBSAN_NULL != 'n') & FORTIFY_SOURCE == 'y' & INFINIBAND_ADDR_TRANS == 'y' & UBSAN_SANITIZE_ALL == 'y' & GENERIC_ALLOCATOR != 'n' & WANXL_BUILD_FIRMWARE != 'y' & AIC7XXX_BUILD_FIRMWARE != 'y' & AIC79XX_BUILD_FIRMWARE != 'y'")[['IPV6', 'UBSAN_ALIGNMENT', 'UBSAN_NULL', 'vmlinux']] # ['cid'].values

(excerpt)

IPV6 | UBSAN_ALIGNMENT | UBSAN_NULL | vmlinux
-- | -- | -- | --
y | y | y | 694670992
y | y | n | 176743080
y | y | n | 197011072
y | y | y | 224274888
n | n | y | -1
y | y | n | 94723816
n | y | n | -1
y | y | y | 89957496
y | y | n | 99956952
n | n | y | -1

basically when IPV6 is 'n' there is systematically a failure... otherwise no issue.
Maybe the deactivation of IPV6 has the (incidental) effect of deactivating the compiler verification