DCL / media_kit / App crash when opening videos from DCL via memory error

[An-anonymous-coder]

Describe the bug When opening a video in the gallery, the app will crack with a DCL via memory error on GrapheneOS.

To Reproduce Steps to reproduce the behavior:

1. Restrict the DCL via memory permission in Settings > Apps > Aves > DCL via memory > Restricted
2. Open Aves
3. Tap on any video
4. The app will crash

Expected behavior The app should not crash

System information and logs:

Package: deckers.thibault.aves
Installer: dev.imranr.obtainium
Aves version: 1.11.17-izzy, build 13602
Flutter: stable 3.24.4
Android version: 15, API 35
Android build: 2024102400
Device: Google Pixel 8
Support: dynamic colors=true, geocoder=false, HDR=true
Mobile services: not available
Connectivity: none
System locales: en_US
Storage volumes: /storage/emulated/0/
Storage grants: /storage/emulated/0/Movies/, /storage/emulated/0/Pictures/, /storage/emulated/0/DCIM/
Error reporting: false

aves-logs-20241030_212229.txt

[An-anonymous-coder]

Also scrubbing videos is really laggy, I'm not sure if GrapheneOS messes with hardware acceleration or not. Can anyone else confirm this?

[deckerst]

What's "DCL via memory" and why do you need it?

[An-anonymous-coder]

What's "DCL via memory" and why do you need it?

Dynamic Code Loading via memory (aka DCL via memory) is an exploitation prevention feature offered by GrapheneOS. Info from their Features Overview about it is below:

"The vast majority of local and remote code execution vulnerabilities are memory corruption bugs caused by memory unsafe languages or rare low-level unsafe code in an otherwise memory safe language. Most of the remaining issues are caused by dynamic code execution/loading features. Our main focus is on preventing or raising the difficulty of exploiting memory corruption bugs followed by restricting dynamic code execution both to make escalation from a memory corruption bug harder and to directly mitigate bugs caused by dynamic code loading/generation/execution such as a JIT compiler bug or a plugin loading vulnerability."

[deckerst]

So you don't need it and can use the app without this "feature", right?

[An-anonymous-coder]

DCL via memory is a permission toggle, like restricting microphone access. I can weaken the permissions to use the app, but it provides less protection against potential exploitation.

[randomwithnoname]

Explanation from GrapheneOS developers (muhomorr & thestinger): https://github.com/simplex-chat/simplex-chat/issues/4810#issuecomment-2349896219

[matchboxbananasynergy]

So you don't need it and can use the app without this "feature", right?

It's an opt-in security feature. People can toggle this globally or per-app. Dynamic code loading is generally discouraged in Android and it would be best practice for the app to work without requiring that, but people are able to use this app without this optional security hardening measure.

See https://developer.android.com/privacy-and-security/risks/dynamic-code-loading.

[deckerst]

Then I'd suggest you take it to media-kit. I suppose you can reproduce that crash with their test app.

[matchboxbananasynergy]

Then I'd suggest you take it to media-kit. I suppose you can reproduce that crash with their test app.

Will take a look.

[matchboxbananasynergy]

I've had a confirmation from a community member that media-kit's test app does indeed use DCL and crashes if it's restricted, so an issue should be opened in the media-kit repo for this, as Aves just makes use of media-kit and can't realistically change how it works.

@deckerst If possible, it might make sense to keep this issue open even when an issue opened in media-kit's repo, as people won't know what's going on and will assume it has to do with the app itself. Having it open will hopefully lead to people reading this rather than making a new issue.

Thanks!

[deckerst]

Similar past issue:

• 722

[shift18]

This issue also affects images.

1. Open Aves
2. Open and close a few image (maybe three)
3. Crash

................................................................. version 1.11.17

deckers.thibault.aves versionCode 136

targetSdk 35 minSdk 21

DCL via memory disabled .................................................................

OS GrapheneOS Build: 2024103100 Android 15

11-02 22:29:49.838  9478  9523 F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 9523 (1.ui), pid 9478 (s.thibault.aves)
11-02 22:29:50.454  9602  9602 F DEBUG   : Abort message: '../../../flutter/third_party/dart/runtime/vm/virtual_memory_posix.cc: 428: error: mprotect failed: 13 (Permission denied)'

Complete logcat available at request

[deckerst]

@shift18 are they pure images? Motion photos contain a video, AVIF are containerised images, etc. So I'm wondering whether you see this with say basic JPEGs or PNGs.

Also, it's possible that while you browse images, there is some cataloguing going on in parallel, and the cataloguing could be handling a video (or some other special file), which would be the trigger.

[shift18]

@shift18 are they pure images? Motion photos contain a video, AVIF are containerised images, etc. So I'm wondering whether you see this with say basic JPEGs or PNGs.

Also, it's possible that while you browse images, there is some cataloguing going on in parallel, and the cataloguing could be handling a video (or some other special file), which would be the trigger.

After checking, no it appears the app only crash when viewing motion pictures. With this in mind i rechecked to see when the app crashes and the app consistently crashes as soon as i open a motion picture while it this does not appears to happen when opening regular images.

Sorry for the confusion, i never capture motion pictures intentionally.

[deckerst]

Here's a test build of the libre flavour (built for arm64-v8a): aves-arm64-v8a-libre-profile_20241111_1200_issue1271

It's using the latest media-kit, including a PR that fixes crashes on systems where DCL is restricted.

Please test the build and let me know whether it works for you.

[randomwithnoname]

It plays the videos fine without crashing but still says it's trying to perform DCL via memory

type: memory_DCL
osVersion: google/akita/akita:15/AP3A.241105.007/2024110700:user/release-keys
package: deckers.thibault.aves.libre.profile:13602, targetSdk 35

package: deckers.thibault.aves.libre.profile:13602

DCL denial type: DENY_EXECMEM

[cillyvms]

It currently switches to a different way of running the player when DCL is not available, so it tries to do DCL to check its status. Fixing this would require a change in Dart, so that might not come soon. You can just click on Don't show again in the notification and it should work fine.

[deckerst]

To those who didn't check what went on in media-kit repo, i'd like to point out that @cillyvms is the wizard who fixed the issue. Thanks!

[randomwithnoname]

It currently switches to a different way of running the player when DCL is not available, so it tries to do DCL to check its status. Fixing this would require a change in Dart, so that might not come soon. You can just click on Don't show again in the notification and it should work fine.

Thanks!