Sources:
https://bugs.chromium.org/p/project-zero/issues/detail?id=796
https://bugs.chromium.org/p/project-zero/issues/detail?id=795

The usermode audio subsystem for the "Samsung Android Professional Audio" is 
based on JACK, which appears to be designed for single-user usage. The common 
JACK configuration on Linux systems appears to be a JACK server running under 
the current user account, and interacting with JACK clients from the same user 
account; so with a minimal privilege difference; this is not the case with the 
configuration on Android, where the JACK service runs as a more privileged user 
in a less restrictive SELinux domain to the clients that can connect to it.

The shared memory implementation (implemented by com.samsung.android.IAndroidShm
system service) allows any application to access/modify/map shared memory pages 
used by JACK, regardless of which application created those shared memory pages.

(NB: This possibly results in breaking the Android permissions model and 
permitting applications without the required capability to access microphone 
input; this was not investigated further.)

There are multiple possible ways to corrupt the internal state of any of the 
shared-memory backed c++ objects in use; attached is a PoC that uses the shared 
memory service to map the JackEngineControl object in use, and modify the value 
of the fDriverNum member, which is used in several places without validation. 

This is highly likely not the only variable stored in shared memory that is used
without proper validation; and the function shown below is definitely not the
only place that this particular variable is used dangerously. To secure this 
interface it will be necessary to review all uses of variables stored in these
shared memory interfaces.

/*!
\brief Engine control in shared memory.
*/

PRE_PACKED_STRUCTURE
struct SERVER_EXPORT JackEngineControl : public JackShmMem
{
    // Shared state
    jack_nframes_t fBufferSize;
    jack_nframes_t fSampleRate;
    bool fSyncMode;
    bool fTemporary;
    jack_time_t fPeriodUsecs;
    jack_time_t fTimeOutUsecs;
    float fMaxDelayedUsecs;
    float fXrunDelayedUsecs;
    bool fTimeOut;
    bool fRealTime;
    bool fSavedRealTime;  // RT state saved and restored during Freewheel mode
    int fServerPriority;
    int fClientPriority;
    int fMaxClientPriority;
    char fServerName[JACK_SERVER_NAME_SIZE+1];
    JackTransportEngine fTransport;
    jack_timer_type_t fClockSource;
    int fDriverNum;
    bool fVerbose;

    // CPU Load
    jack_time_t fPrevCycleTime;
    jack_time_t fCurCycleTime;
    jack_time_t fSpareUsecs;
    jack_time_t fMaxUsecs;
    jack_time_t fRollingClientUsecs[JACK_ENGINE_ROLLING_COUNT];
    unsigned int fRollingClientUsecsCnt;
    int	fRollingClientUsecsIndex;
    int	fRollingInterval;
    float fCPULoad;

    // For OSX thread
    UInt64 fPeriod;
    UInt64 fComputation;
    UInt64 fConstraint;

    // Timer
    JackFrameTimer fFrameTimer;

#ifdef JACK_MONITOR
    JackEngineProfiling fProfiler;
#endif

    ...

This is quite a convenient exploitation primitive, as a small negative value 
will cause the code in several places to index backwards from a known array;
when (any of the similar functions to the below are called, table is pointing
to the fClientTable array inside a JackEngine instance)

void JackTransportEngine::MakeAllLocating(JackClientInterface** table)
{
    for (int i = GetEngineControl()->fDriverNum; i < CLIENT_NUM; i++) {
        JackClientInterface* client = table[i];
        if (client) {
            JackClientControl* control = client->GetClientControl();
            control->fTransportState = JackTransportStopped;
            control->fTransportSync = true;
            control->fTransportTimebase = true;
            jack_log("MakeAllLocating ref = %ld", i);
        }
    }
}

class SERVER_EXPORT JackEngine : public JackLockAble
{
    friend class JackLockedEngine;

    private:

        JackGraphManager* fGraphManager;
        JackEngineControl* fEngineControl;
        char fSelfConnectMode;
        JackClientInterface* fClientTable[CLIENT_NUM];

We can see that just behind the fClientTable, we have two pointers to other
objects; a JackEngineControl and a JackGraphManager, both of which are backed by
shared memory. Since we are treating the pointer read from table as a c++ object
with a vtable pointer, this lets us trivially gain control of the flow of 
execution.

 Fatal signal 11 (SIGSEGV), code 1, fault addr 0x41414140 in tid 27197 (jackd)
 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
 Build fingerprint: 'samsung/zeroltexx/zerolte:6.0.1/MMB29K/G925FXXU3DPAD:user/release-keys'
 Revision: '10'
 ABI: 'arm'
 pid: 27181, tid: 27197, name: jackd  >>> /system/bin/jackd <<<
 AM write failed: Broken pipe
 signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x41414140
     r0 f3f1a000  r1 f48c2010  r2 f48c2010  r3 41414141
     r4 f3f1a000  r5 00000036  r6 f3dbf930  r7 00000078
     r8 f72c8b9c  r9 f6f1a308  sl f3d3f000  fp f719a991
     ip f71d7a0c  sp f3dbf7d8  lr f7196c43  pc 41414140  cpsr 800f0030
 
 backtrace:
     #00 pc 41414140  <unknown>
     #01 pc 0003cc41  /system/lib/libjackserver.so (Jack::JackTransportEngine::MakeAllLocating(Jack::JackClientInterface**)+52)
     #02 pc 0003cda1  /system/lib/libjackserver.so (Jack::JackTransportEngine::CycleEnd(Jack::JackClientInterface**, unsigned int, unsigned int)+228)
     #03 pc 00048bd5  /system/lib/libjackserver.so
     #04 pc 00049211  /system/lib/libjackserver.so (Jack::JackEngine::Process(unsigned long long, unsigned long long)+228)
     #05 pc 000442fd  /system/lib/libjackserver.so
     #06 pc 00044f49  /system/lib/libjackserver.so (Jack::JackAudioDriver::ProcessGraphSyncMaster()+40)
     #07 pc 00044f0d  /system/lib/libjackserver.so (Jack::JackAudioDriver::ProcessGraphSync()+20)
     #08 pc 00044e87  /system/lib/libjackserver.so (Jack::JackAudioDriver::ProcessSync()+94)
     #09 pc 00044bbf  /system/lib/libjackserver.so (Jack::JackAudioDriver::Process()+22)
     #10 pc 0004fff1  /system/lib/libjackserver.so (Jack::JackThreadedDriver::Process()+24)
     #11 pc 0005051f  /system/lib/libjackserver.so (Jack::JackThreadedDriver::Execute()+18)
     #12 pc 00040a0f  /system/lib/libjackserver.so (Jack::JackAndroidThread::ThreadHandler(void*)+126)
     #13 pc 0003fc53  /system/lib/libc.so (__pthread_start(void*)+30)
     #14 pc 0001a38b  /system/lib/libc.so (__start_thread+6)
 
 Tombstone written to: /data/tombstones/tombstone_05

################################################################################################################

The usermode audio subsystem for the "Samsung Android Professional Audio" is 
based on JACK, which appears to be designed for single-user usage. The common 
JACK configuration on Linux systems appears to be a JACK server running under 
the current user account, and interacting with JACK clients from the same user 
account; so with a minimal privilege difference; this is not the case with the 
configuration on Android, where the JACK service runs as a more privileged user 
in a less restrictive SELinux domain to the clients that can connect to it.

The JACK shared memory implementation uses the struct jack_shm_info_t defined in
/common/shm.h to do some bookkeeping

PRE_PACKED_STRUCTURE
struct _jack_shm_info {
    jack_shm_registry_index_t index;       /* offset into the registry */
    uint32_t size;
#ifdef __ANDROID__
    jack_shm_fd_t fd;
#endif
    union {
        void *attached_at;  /* address where attached */
        char ptr_size[8];
    } ptr;  /* a "pointer" that has the same 8 bytes size when compling in 32 or 64 bits */
} POST_PACKED_STRUCTURE;

typedef struct _jack_shm_info jack_shm_info_t;

This struct is stored at the start of every JackShmAble object.

/*!
\brief
A class which objects possibly want to be allocated in shared memory derives from this class.
*/

class JackShmMemAble
{
    protected:

        jack_shm_info_t fInfo;

    public:

        void Init();

        int GetShmIndex()
        {
            return fInfo.index;
        }

        char* GetShmAddress()
        {
            return (char*)fInfo.ptr.attached_at;
        }

        void LockMemory()
        {
            LockMemoryImp(this, fInfo.size);
        }

        void UnlockMemory()
        {
            UnlockMemoryImp(this, fInfo.size);
        }

};

This means that whenever the JACK server creates an object backed by shared 
memory, it also stores a pointer to that object (in the address space of the 
JACK server), allowing a malicious client to bypass ASLR in the JACK server 
process. 

The PoC provided for the other reported JACK issue uses this to bypass ASLR in 
the JACK server process.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40066.zip