Chromium 88 crashes on 32bit Slackware with glibc-2.33

[Eric Hameleers]

The latest chromium releases (88.x) are all crashing on our 32bit Slackware OS with glibc 2.33 installed.

The crash shows several of these error lines:

../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-

bpf failure in syscall 0422

Received signal 11 SEGV_ACCERR 00000898c1a6

And actually ArchLinux32 is reporting the exact same crash behavior but then in qt5-webengine, i.e. also in chromium: https://bbs.archlinux32.org/viewtopic.php?id=3055

Now there was a debian patch a while ago which is widely used in 32bit distros: https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/patches/sandbox-time64-syscalls.patch . It adresses similar cases introduced by glibc 2.31 and before Chromium 88, that patch was sufficient but the new crash needs to be addressed. Who can help? I was unsuccessful.

Thanks Eric

[Eric Hameleers]

Hi Matt,

Would be much appreciated!

Thanks, Eric

On Wed, 24 Feb 2021, Matt Denton wrote:

> Date: Wed, 24 Feb 2021 20:52:12 -0800
> From: Matt Denton <mpde...@google.com>
> To: Tom Anderson <thomasa...@google.com>
> Cc: Eric Hameleers <al...@slackware.com>,
> chromium-packagers <chromium-...@chromium.org>
> Subject: Re: [chromium-packagers] Chromium 88 crashes on 32bit Slackware with
> glibc-2.33
>
> Sure, I'll take a look Thursday or Friday.
>
> On Tue, Feb 23, 2021 at 11:05 AM Tom Anderson <thomasa...@google.com>
> wrote:
>
>> +Matt Denton <mpde...@google.com> Would you or other
>> //sandbox/linux/OWNERS be able to change the seccomp policy to allow the
>> new syscalls used by glibc?
>>
>> There's also a bug reporting similar issues:
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1164975

>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "chromium-packagers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to chromium-packag...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/0306d0a7-009d-4f72-b8f7-d6780cf1a810n%40chromium.org
>>> <https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/0306d0a7-009d-4f72-b8f7-d6780cf1a810n%40chromium.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>

Cheers, Eric

--
Eric Hameleers <al...@slackware.com>
Home: http://alien.slackbook.org/blog/

[Tom Anderson]

+Matt Denton Would you or other //sandbox/linux/OWNERS be able to change the seccomp policy to allow the new syscalls used by glibc?

There's also a bug reporting similar issues:

https://bugs.chromium.org/p/chromium/issues/detail?id=1164975

On Mon, Feb 22, 2021 at 12:23 AM Eric Hameleers <al...@slackware.com> wrote:

--

You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/0306d0a7-009d-4f72-b8f7-d6780cf1a810n%40chromium.org.

[Eric Hameleers]

Note that the bug I reported for 32bit Slackware is different from the one referenced by Tom. Please provide a fix for these ":**CRASHING**:seccomp-
bpf failure in syscall 0422" issues. Having to disable the sandbox to allow the browser to run is not an acceptable workaround.

Thanks! Eric

Op maandag 8 maart 2021 om 21:18:12 UTC+1 schreef Tom Anderson:

[Eric Hameleers]

Hi Matt

I can confirm that with that patch applied, the new Chromium
89.0.4389.90 is no longer crashing on startup on 32-bit Slackware.
Thanks!

On Thu, 11 Mar 2021, Matt Denton wrote:

> Thanks Eric, I've uploaded a CL for this particular syscall:
> https://chromium-review.googlesource.com/c/chromium/src/+/2753571

[Eric Hameleers]

Hi Matt

Unfortunately the saga continues - now with the next unimplemented
syscall (0383):

../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf
failure in syscall 0383
Received signal 11 SEGV_MAPERR 00000497717f

Is there a way to fix this in one patch for all possible future cases?
I assume we haven't seen the last of this...