Re: [PATCH RFC v1] m68k: signal.c: use signal frame gap to avoid stack corruption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Andreas,

Am 29.04.2023 um 20:17 schrieb Andreas Schwab:
On Apr 29 2023, Michael Schmitz wrote:

We can use the format b fault address in frame.un.fmtb.daddr
to find the address where the fault occurred, i.e. the
address where the instruction will resume.

I don't think you can assume any order of transfer.

True - I've been seeing this too much through the lens of this particular bug - moveml to user stack faulting while crossing a page boundary.

The more typical case appears to look like this:

[ 4703.880000] get_sigframe: signal stack 0xeffff758 fault daddr 0x8003f328
[ 5009.830000] get_sigframe: signal stack 0xefffef80 fault daddr 0x80029c88
[ 6152.750000] get_sigframe: signal stack 0xeffff3a4 fault daddr 0x8006a290
[ 6985.290000] get_sigframe: signal stack 0xeffff3a4 fault daddr 0x8006a290
[ 7260.060000] get_sigframe: signal stack 0xeffff020 fault daddr 0x80050cec
[ 7794.080000] get_sigframe: signal stack 0xc0001ea0 fault daddr 0x8000c69c
[ 7797.240000] get_sigframe: signal stack 0xeffff08c fault daddr 0xc00f4f7e
[ 7942.460000] get_sigframe: signal stack 0xeffff3a4 fault daddr 0x80050cec
[ 9833.180000] get_sigframe: signal stack 0xeffff3a4 fault daddr 0x80050cec
[10153.500000] get_sigframe: signal stack 0xeffff020 fault daddr 0x8006a290
[10781.110000] get_sigframe: signal stack 0xeffff3c8 fault daddr 0x800435dc
[11648.290000] get_sigframe: signal stack 0xeffff8f0 fault daddr 0x800024f0
[11773.260000] get_sigframe: signal stack 0xeffff3d0 fault daddr 0x8002f858
[12117.380000] get_sigframe: signal stack 0xeffffa08 fault daddr 0x8006a290
[12526.350000] get_sigframe: signal stack 0xefffef78 fault daddr 0xc006fba0
[12875.800000] get_sigframe: signal stack 0xc043de08 fault daddr 0x800b5f68
[15682.160000] get_sigframe: signal stack 0xeffff8f0 fault daddr 0xc00c37c8
[16503.110000] get_sigframe: signal stack 0xeffff730 fault daddr 0x80050cec
[16545.560000] get_sigframe: signal stack 0xeffff6ac fault daddr 0x80050cec

Fault address and USP are entirely unrelated (and no risk of overwriting the area where the fault occurred).

My (rather convoluted) checks that are meant to ensure fault address and stack pointer are on immediately adjacent pages, and not miles apart should take care of these above cases.

But I had indeed overlooked the case of crossing a page boundary upwards. Thanks for pointing that out.

As it turns out, in this case using the area on the user stack immediately below USP won't hurt - the transfer direction is away from the end of the signal frame, and as long as the signal stack remains below USP, it does not overwrite anything already on the stack that a resume would miss. No need to shift the signal frame out of the way.

What else am I missing? Examination of the stack contents from the signal handler before resuming the movem through rte has shown the order and direction of transfer is as expect for @sp-, i.e. downwards...

Cheers,

	Michael



[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux