system reboots due to memory corruption detected by heap canaries and UAF detection in zygote

[canary5]

I have almost daily systems restarts. Not sure when it started, i think from march.
This error in logs always:
Fatal signal 6 (SIGABRT), code -6
Do you need full adb?

[thestinger]

I need more information than that.

[thestinger]

I need more information than that.

[thestinger]

The device you're using, logs, whether it's a pristine install (i.e. whether stuff like gapps has been sidedloaded), etc.

[thestinger]

The device you're using, logs, whether it's a pristine install (i.e. whether stuff like gapps has been sidedloaded), etc.

[canary5]

Device 5x, all version from March i think but not 100% sure. Clean Os no gapps, just few apps more installed. I have older log and todays, i will post little later

[canary5]

Device 5x, all version from March i think but not 100% sure. Clean Os no gapps, just few apps more installed. I have older log and todays, i will post little later

[canary5]

Sent logs by emeil

[canary5]

Sent logs by emeil

[thestinger]

Appears to be an upstream bug detected by OpenBSD malloc then. Not much that can be done about it because I don't have the resources to consider those in-scope right now. You can turn off canaries in Settings -> Security -> Advanced and it will probably turn back into silent memory corruption like stock rather than being detected.

[thestinger]

Appears to be an upstream bug detected by OpenBSD malloc then. Not much that can be done about it because I don't have the resources to consider those in-scope right now. You can turn off canaries in Settings -> Security -> Advanced and it will probably turn back into silent memory corruption like stock rather than being detected.

[canary5]

But those security options the reason me using Cos;)) but before march it never happened. March updates fixed overall performance and battery, so i can live one system reboot daily. If need more logs every reboot i can provide

[canary5]

But those security options the reason me using Cos;)) but before march it never happened. March updates fixed overall performance and battery, so i can live one system reboot daily. If need more logs every reboot i can provide

[thestinger]

The security features in the Settings app are only the ones deemed too expensive performance-wise to enable by default. Only a few features are exposed there. Most of the security features are already there by default.

CopperheadOS follows the upstream releases, which is where the performance and battery life improvements came from. Apparently, the new branch also introduced this memory corruption issue. It's not a bug in our code and we don't have the resources to address upstream bugs in Android. I was doing it before, but I no longer want to spend my free time on that.

[thestinger]

The security features in the Settings app are only the ones deemed too expensive performance-wise to enable by default. Only a few features are exposed there. Most of the security features are already there by default.

CopperheadOS follows the upstream releases, which is where the performance and battery life improvements came from. Apparently, the new branch also introduced this memory corruption issue. It's not a bug in our code and we don't have the resources to address upstream bugs in Android. I was doing it before, but I no longer want to spend my free time on that.

[canary5]

Ok, tnx for great work. So those 2 canaries options need to be disabled right to fix memory corruprion? And its just 5x or 6p problems as well?

[canary5]

Ok, tnx for great work. So those 2 canaries options need to be disabled right to fix memory corruprion? And its just 5x or 6p problems as well?

[thestinger]

Disabling the canary option (just that single one) is enough to avoid the issue from your logs. It won't fix the memory corruption. That's an upstream bug that is going to occur regardless. It's just not going to make the process abort, since the feature that's able to detect it will be disabled.

[thestinger]

Disabling the canary option (just that single one) is enough to avoid the issue from your logs. It won't fix the memory corruption. That's an upstream bug that is going to occur regardless. It's just not going to make the process abort, since the feature that's able to detect it will be disabled.

[canary5]

I disabled it, but got another reboot today. Log sent by email

[canary5]

I disabled it, but got another reboot today. Log sent by email

[thestinger]

That's another memory corruption issue from upstream (use-after-free). Not much that I can do about all of these issues.

[thestinger]

That's another memory corruption issue from upstream (use-after-free). Not much that I can do about all of these issues.

[thestinger]

Logs aren't enough to fix issues like this. It gives a backtrace from where it was detected (the free causing the allocation that was used after free to be moved from the quarantine), not where the issue actually occurred. It's designed as a hardening feature, not a debugging one. The same thing applies to canaries: it finds out on free, not when the canary was overwritten. There's very little that can be done without setting up debugging, but I can't reproduce the issues so there's nothing to do.

[thestinger]

Logs aren't enough to fix issues like this. It gives a backtrace from where it was detected (the free causing the allocation that was used after free to be moved from the quarantine), not where the issue actually occurred. It's designed as a hardening feature, not a debugging one. The same thing applies to canaries: it finds out on free, not when the canary was overwritten. There's very little that can be done without setting up debugging, but I can't reproduce the issues so there's nothing to do.

[thestinger]

Ideally the root causes of these issues could be identified, so it could reproduced. If it's a rare issue that's infeasible to reproduce, there's little hope of a fix.

[thestinger]

Ideally the root causes of these issues could be identified, so it could reproduced. If it's a rare issue that's infeasible to reproduce, there's little hope of a fix.

[thestinger]

(at least without trying to find it with ASan or Valgrind, but the canaries can be more precise... yet they aren't going to have enough debugging information to work from in such large processes)

[thestinger]

(at least without trying to find it with ASan or Valgrind, but the canaries can be more precise... yet they aren't going to have enough debugging information to work from in such large processes)

[canary5]

What is recommended quarantine size, that new option. Is it related to reboots?

[canary5]

What is recommended quarantine size, that new option. Is it related to reboots?

[thestinger]

It controls the memory usage dedicated to the quarantine. It's set to 32 by default, and only setting it to 0 would eliminate it as a bug finding feature completely. None of these switches is meant to alter stability: there shouldn't be so many memory corruption bugs in normal code paths, and it needs to be fixed upstream ASAP.

[thestinger]

It controls the memory usage dedicated to the quarantine. It's set to 32 by default, and only setting it to 0 would eliminate it as a bug finding feature completely. None of these switches is meant to alter stability: there shouldn't be so many memory corruption bugs in normal code paths, and it needs to be fixed upstream ASAP.

[thestinger]

Fixing all memory corruption issues in Android is out-of-scope. I'm willing to do some work on it, but I need reproducible bugs, i.e. I need to know how to trigger this. It's not a bug in anything CopperheadOS added, the feature is working as intended (triggering aborts / faults when memory corruption happens).

[thestinger]

Fixing all memory corruption issues in Android is out-of-scope. I'm willing to do some work on it, but I need reproducible bugs, i.e. I need to know how to trigger this. It's not a bug in anything CopperheadOS added, the feature is working as intended (triggering aborts / faults when memory corruption happens).