On Tue, 2020-05-19 at 08:59 +0800, Jeremy Kerr wrote:
> Hi Stan,
>
> > The new kernel compiled and booted with no errors, with these
> > STACKPROTECTOR options in .config (the last two revealed the bug):
> >
> > CONFIG_HAVE_STACKPROTECTOR=y
> > CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
> > CONFIG_STACK
Hi Stan,
> The new kernel compiled and booted with no errors, with these
> STACKPROTECTOR options in .config (the last two revealed the bug):
>
> CONFIG_HAVE_STACKPROTECTOR=y
> CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
> CONFIG_STACKPROTECTOR=y
> CONFIG_STACKPROTECTOR_STRONG=y
Brilliant, thanks for te
Hi Finn,
> This fixes an old bug recently revealed by CONFIG_STACKPROTECTOR.
Good catch. I'm not sure about the fix though. That variable ('addr')
should be a ethernet hardware address; I'm surprised we're accessing
past the 6th byte. The culprit seems to be this, where 'ea' is the
address buffer
This fixes an old bug recently revealed by CONFIG_STACKPROTECTOR.
[ 25.707616] scsi host0: MESH
[ 28.488852] eth0: BMAC at 00:05:02:07:5a:a6
[ 28.488859]
[ 28.505397] Kernel panic - not syncing: stack-protector: Kernel stack is
corrupted in: bmac_probe+0x540/0x618
[ 28.535152] CPU: 0 PI
