Michael, On 2/10/23 12:55 AM, Michael Schmitz wrote: > ... > > Without Al's patch, I doubt even in case a uaccess fault happens with > signal pending we'd return -1 from send_fault_sig() (the no_context path > isn't taken and do_page_fault() returns without error). No kernel > messages expected in that case. But none seen otherwise either which > indicates exception handling in uaccess isn't a problem. > > Not sure it's worth the hassle to retry with both patches applied... > ...
I'm going to assume that the stack smashing is not a kernel issue and is either a config options issue on my part or something that is new and hasn't been seen before. There aren't enough working kernels to do a git bisect, anyway, plus I haven't found one that boots that doesn't have stack smashing (and losing the rootfs is inconvenient). bad -> has stack smashing x -> fails to compile kernel status notes v5.15 bad no rootfs corruption v5.10 bad no rootfs corruption v5.5 bad no rootfs corruption v5.1 x SCSI2SD crashes, goes offline with activity LED on, rootfs corrupted, needed to be restored from backups, SCSI2SD SD card needed to have the Apple driver updated to boot MacOS v4.20 bad stack smashing on first boot, corrupted rootfs (bad superblock magic number) on second boot, fsck from a different rootfs found many block counts wrong, rootfs had to be restored from backups v4.0 x looking for include/linux/compiler-gcc.h So I'll look for issues with executables in the sysvinit startup scripts (I previously found what appeared to be an issue in /etc/rcS.d/S01mountkernfs.sh) and I'll send an update if I find anything. As Finn pointed out, I'm only seeing the stack smashing with kernels that I've built. So it may be a non-problem for this list. thanks -Stan
