dahdi-base: fix potential underflow of unsigned type

[dangowrt]

Compile fails on newer kernels due to better fortification of memcpy calls.

In function 'strncat',
    inlined from 'dahdi_ioctl_get_version' at dahdi-linux-3.4.0/drivers/dahdi/dahdi-base.c:5405:3:
./include/linux/fortify-string.h:114:33: error: '__builtin_memcpy' accessing 4294967295 bytes at offsets [80, 238] and 0 overlaps 6442450943 bytes at offset -2147483648 [-Werror=restrict]
  114 | #define __underlying_memcpy     __builtin_memcpy
      |                                 ^
./include/linux/fortify-string.h:457:9: note: in expansion of macro '__underlying_memcpy'
  457 |         __underlying_memcpy(p + p_len, q, copy_len);
      |         ^~~~~~~~~~~~~~~~~~~

Fix this by avoiding a potential underflow of unsigned type size_t.

[sangoma-oss-cla]

All committers have signed the CLA.

[InterLinked1]

Compile fails on newer kernels due to better fortification of memcpy calls.

In function 'strncat',
    inlined from 'dahdi_ioctl_get_version' at dahdi-linux-3.4.0/drivers/dahdi/dahdi-base.c:5405:3:
./include/linux/fortify-string.h:114:33: error: '__builtin_memcpy' accessing 4294967295 bytes at offsets [80, 238] and 0 overlaps 6442450943 bytes at offset -2147483648 [-Werror=restrict]
  114 | #define __underlying_memcpy     __builtin_memcpy
      |                                 ^
./include/linux/fortify-string.h:457:9: note: in expansion of macro '__underlying_memcpy'
  457 |         __underlying_memcpy(p + p_len, q, copy_len);
      |         ^~~~~~~~~~~~~~~~~~~

Fix this by avoiding a potential underflow of unsigned type size_t.

Just curious, what kernels are you seeing this on? I haven't encountered this yet.

[dangowrt]

I found this issue when trying to build DAHDI on Linux 6.12 with GCC 14 and fortify headers. It probably won't trigger an error without using fortify headers.

[InterLinked1]

I found this issue when trying to build DAHDI on Linux 6.12 with GCC 14 and fortify headers. It probably won't trigger an error without using fortify headers.

That would explain it.
Could you share instructions to reproduce? I'd like to capture this in the builds for better futureproofing.

[dangowrt]

Set CONFIG_FORTIFY_SOURCE=y in your kernel .config, see also
https://github.com/torvalds/linux/blob/dee264c16a6334dcdbea5c186f5ff35f98b1df42/security/Kconfig.hardening#L209

[InterLinked1]

Set CONFIG_FORTIFY_SOURCE=y in your kernel .config, see also https://github.com/torvalds/linux/blob/dee264c16a6334dcdbea5c186f5ff35f98b1df42/security/Kconfig.hardening#L209

Thanks, I still haven't been able to reproduce this, with either gcc 13 or gcc 15. I'm trying against linux-next and confirmed CONFIG_FORTIFY_SOURCE=y - anything else I might be missing?

cd /usr/src/linux-next
make -j$(nproc) kernelversion
make -j$(nproc) x86_64_defconfig
./scripts/config --set-val CONFIG_FORTIFY_SOURCE y
make -j$(nproc) modules_prepare
cat .config
make -j$(nproc)
make -j$(nproc) modules

[dangowrt]

I noticed this error when building for a MIPS32-based embedded platform, which obviously changes sizeof(size_t) as well as sizeof() other basic types compared to x86_64. I can share the complete kernel .config file if that helps.

[InterLinked1]

I noticed this error when building for a MIPS32-based embedded platform, which obviously changes sizeof(size_t) as well as sizeof() other basic types compared to x86_64. I can share the complete kernel .config file if that helps.

Hmm... that's probably it then. My builds are only testing x86 since that's all GitHub supports.
But yeah, I'd still be interested in trying to manually reproduce this for the future - thanks!