CtsSecurityTestCases fail

[hungeason]

We use android 7.1.1 to run CTS ,and we got cts fail as below:

android.security.cts.StagefrightTest#testStagefright_bug_21443020

android.security.cts.StagefrightTest#testStagefright_bug_27855419_CVE_2016_2463

android.security.cts.StagefrightTest#testStagefright_bug_32322258

android.security.cts.StagefrightTest#testStagefright_bug_32873375

android.security.cts.StagefrightTest#testStagefright_bug_32915871

android.security.cts.StagefrightTest#testStagefright_bug_33137046

android.security.cts.StagefrightTest#testStagefright_bug_33818508

android.security.cts.StagefrightTest#testStagefright_cve_2015_6600

android.security.cts.StagefrightTest#testStagefright_cve_2016_2429_b_27211885

android.security.cts.ZeroHeightTiffTest#test_android_bug_33300701

...etc

The fail log could be one of  situation as below

1.Test failed to run to completion. Reason: 'Instrumentation run failed due to 'Process crashed.''. Check device logcat for details

2.junit.framework.AssertionFailedError: Device *IS* vulnerable to HTTP://LOCALHOST:41717/ASSETS/RAW/CVE-2015-1538-2

What situation cause this problem ?Does it is success on NXP board?

[philweeks]

we are current with the BSP...we will be submitting again to Google in September...i would still like feedback on the patch i provided as it does definitely fix the issues and we havent seen any other fix from NXP...thanks

[diegoadrian]

Hello Phill,

I apologize for the delay.

Can you please help me with the below questions of the apps engineer?

- Is the customer using N7.1.1_1.0.0 GA provided by NXP?
- Which CTS version is the customer using?
- Which i.MX device is the customer using?

Another thing, I believe that upgrading to android N7.1.2_2.0.0_GA may help with this issue.

The following tests are marked as passed which fails in the customer side:

android.security.cts.StagefrightTest#testStagefright_bug_27855419_CVE_2016_2463
android.security.cts.StagefrightTest#testStagefright_bug_32322258
android.security.cts.StagefrightTest#testStagefright_bug_32873375
android.security.cts.StagefrightTest#testStagefright_bug_32915871
android.security.cts.StagefrightTest#testStagefright_bug_33137046
android.security.cts.StagefrightTest#testStagefright_cve_2015_6600
android.security.cts.StagefrightTest#testStagefright_cve_2016_2429_b_27211885
android.security.cts.ZeroHeightTiffTest#test_android_bug_33300701

Again, I apologize for the delay.

Best Regards,

Diego

[philweeks]

- Is the customer using N7.1.1_1.0.0 GA provided by NXP? (not sure...where would i get it? i found it here https://community.nxp.com/docs/DOC-334034 )
- Which CTS version is the customer using? (5.1.1_R22 through 5.1.1_R25)
- Which i.MX device is the customer using? (imx6)

Another thing, I believe that upgrading to android N7.1.2_2.0.0_GA may help with this issue. (where would i get it? i could not find it as i found the N7.1.1_1.0.0 GA)

thanks

[diegoadrian]

Hello,

You can find it on this web-page.

Android OS for i.MX Applications Processors|NXP 

Please, download the below file located in the Board Support Packages parts:

IMX_N7.1.2_2.0.0_ANDROID_SOURCE_BSP

Best Regards,

Diego.

[shabaka101694]

Hi, 

  Similar to  Eason I am running android CTS for 7.1.1 and I am also getting the same process crash. Looking into logcat, it appears that the vpu code is returning from an invalid (??) attempt to set a config on the OMXMediaInstance, which causes the cts.android.security process to crash. 

Is it possible for NXP to look into this issue and what the underlying issue is. I am currently attempting to run the CTS test with verbose logging enabled for the vpu_wrapper and OpenMAXIL source code. I will see if any more insight can be gleaned from this 

Thanks 

Victor 

[philweeks]

this problem persists for the CtsTestServer cases. Looking into it, in frameworks/av/media/libmediaservice/MediaFactory.cpp, in the function "scoreFactory", there is a check if the uri is "http" and if it is, it then calls "isWVM" which then checks if the uri is "http" or "https" and then checks if there is http service, and if there isn't it returns false to scoreFactory, which does not react to the false return value or the fact that there is not http service.

Changing the logic so that scoreFactory checks for http service if the uri is http or https and returning 0.0 if no service, fixes the Cts failures. 

I've attached a patch and would like someone from NXP to comment on it please.

Phil

[philweeks]

does anyone from NXP read these forums? Google gave us a temporary waiver because our submission applied to the KRACK fixes, however we are still required to fix these stagefright problems, which my patch appears to do. We need NXP approval of this change or a different fix from NXP...is there a better way to get NXP to reply to this issue?

thanks

[diegoadrian]

Hello, Phil

Let me see internally if someone know if your patch can solve the CTS problem or if someone knows how to solve the problem.

Best Regards,

Diego.

[saiyamdoshi]

Hello,

Have you any update on a patch to fix the "testStagefright_cve_2016_2429_b_27211885"?

Thanks.

[philweeks]

the patch definitely works and makes sense, but it would be nice to have NXP comment on it...i've tried to "bump" the thread regularly, but rarely get a reply from NXP

[philweeks]

is there any update? it's been almost a month and we will most assuredly be doing another google submission soon

thanks,

Phil

[eason]

Using 7.1.1 release images(January 5,2017) on freescale demo board with CTS7.1_R10,and the result still fail as below

android.security.cts.StagefrightTest#testStagefright_bug_21443020 
android.security.cts.StagefrightTest#testStagefright_bug_27855419_CVE_2016_2463 
android.security.cts.StagefrightTest#testStagefright_bug_32322258 
android.security.cts.StagefrightTest#testStagefright_bug_32873375 
android.security.cts.StagefrightTest#testStagefright_bug_32915871 
android.security.cts.StagefrightTest#testStagefright_bug_33137046 
android.security.cts.StagefrightTest#testStagefright_bug_33818508 
android.security.cts.StagefrightTest#testStagefright_cve_2015_1538_2 
android.security.cts.StagefrightTest#testStagefright_cve_2015_1538_4 
android.security.cts.StagefrightTest#testStagefright_cve_2015_6600 
android.security.cts.StagefrightTest#testStagefright_cve_2016_2429_b_27211885 
android.security.cts.StagefrightTest#testStagefright_cve_2016_3755 
android.security.cts.StagefrightTest#testStagefright_cve_2016_3878_b_29493002

[philweeks]

We are also experiencing this bug on 5.1.1_R22 through 5.1.1_R25

StagefrightTest.testStagefright_cve_2016_2429_b_27211885

we also have started seeing 

StagefrightTest.testStagefright_cve_2016_2507

and

StagefrightTest.testStagefright_cve_2015_1538_4

we did not have the patch applied mentioned in the other thread, but like the OP, I applied the patch and still we have failures. Google has said "reach out to your SoC vendor"...can we get an update/fix on all of these?

i'm also seeing the following in logcat (once this starts it does not stop and the phone has to be reset)

11-09 14:35:46.768 3615-4176/? I/OMXPlayer: LEVEL: 1 FUNCTION: appLocalMalloc LINE: 37
11-09 14:35:46.769 3615-4176/? I/OMXPlayer: Error: MEMORY FAILURE IN LOCAL MALLOC

as well as output like the following (this is not the only test to cause this)

11-10 07:55:09.335 165-492/? I/MediaPlayerFactory: Attempt to get video from http URI without HTTP service.
11-10 07:55:09.336 165-492/? I/OMXPlayer: Loading content: http://localhost:45018/assets/raw/bug_23270724_1
11-10 07:55:09.336 165-492/? I/OMXPlayer: LEVEL: 1 FUNCTION: MediaTypeInspect LINE: 1967
11-10 07:55:09.336 165-492/? I/OMXPlayer: Can't inspect media content type by subfix.
11-10 07:55:09.341 2704-2793/? I/CtsTestServer: GET: /assets/raw/bug_23270724_1
11-10 07:55:09.342 2704-2793/? I/CtsTestServer: 200(null)

Thanks

[philweeks]

some more information:

these three failures appeared when CTS was updated to run every stagefright test using local media and media served from CtsTestServer.

It's when the test is run through the CtsTestServer that they fail.

Can someone from NXP comment? we're trying to submit to google before the 27th so we don't have to upgrade CTS and re-run all our tests...even if we get to that point we still need a fix or something to tell Google about why their test is failing when it used to pass

[philweeks]

I still think the issue lies with Google and the CtsTestServer but they're saying its not

After investigation by CTS owner, we found the crash happens in device-specific code. So it needs to be fixed by the partner.

11-17 11:21:29.984   162   162 I DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
11-17 11:21:29.985   465   545 W NativeCrashListener: Couldn't find ProcessRecord for pid 164
11-17 11:21:29.985   162   162 I DEBUG   : Build fingerprint: 'Spectralink/thor_6dq/thor_6dq:5.1.1/LMY47V/20865:user/release-keys'
11-17 11:21:29.985   162   162 I DEBUG   : Revision: '0'
11-17 11:21:29.985   162   162 E DEBUG   : AM write failure (32 / Broken pipe)
11-17 11:21:29.985   162   162 I DEBUG   : ABI: 'arm'
11-17 11:21:29.986   162   162 I DEBUG   : pid: 164, tid: 2631, name: Binder_4  >>> /system/bin/mediaserver <<<
11-17 11:21:29.986   162   162 I DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x83580b9
11-17 11:21:30.024   162   162 I DEBUG   :     r0 083580b9  r1 00002710  r2 00000000  r3 00000000
11-17 11:21:30.024   162   162 I DEBUG   :     r4 083580b9  r5 083580b5  r6 00002710  r7 b68009e8
11-17 11:21:30.024   162   162 I DEBUG   :     r8 00000003  r9 000002bc  sl b3f9cc4c  fp 00000000
11-17 11:21:30.024   162   162 I DEBUG   :     ip b67d3f88  sp b3f9cb40  lr b67d1657  pc b6e4e98e  cpsr 000f0030
11-17 11:21:30.024   162   162 I DEBUG   : 
11-17 11:21:30.024   162   162 I DEBUG   : backtrace:
11-17 11:21:30.025   162   162 I DEBUG   :     #00 pc 0001798e  /system/lib/libc.so (pthread_mutex_lock+7)
11-17 11:21:30.025   162   162 I DEBUG   :     #01 pc 00002653  /system/lib/lib_omx_osal_v2_arm11_elinux.so (fsl_osal_cond_timedwait+10)
11-17 11:21:30.025   162   162 I DEBUG   :     #02 pc 00016cf1  /system/lib/lib_omx_client_arm11_elinux.so (_ZN11GMComponent11WaitCommandE15OMX_COMMANDTYPEmPvx+148)
11-17 11:21:30.025   162   162 I DEBUG   :     #03 pc 00016f4b  /system/lib/lib_omx_client_arm11_elinux.so (_ZN11GMComponent12DoStateTransE13OMX_STATETYPEx+86)
11-17 11:21:30.025   162   162 I DEBUG   :     #04 pc 0001882b  /system/lib/lib_omx_client_arm11_elinux.so (_ZN11GMComponent16StateTransUpWardE13OMX_STATETYPE+118)
11-17 11:21:30.025   162   162 I DEBUG   :     #05 pc 0000fc2b  /system/lib/lib_omx_client_arm11_elinux.so (_ZN8GMPlayer10LoadParserEPc+690)
11-17 11:21:30.025   162   162 I DEBUG   :     #06 pc 00011483  /system/lib/lib_omx_client_arm11_elinux.so (_ZN8GMPlayer4LoadEPc+266)
11-17 11:21:30.025   162   162 I DEBUG   :     #07 pc 000086e9  /system/lib/lib_omx_client_arm11_elinux.so
11-17 11:21:30.025   162   162 I DEBUG   :     #08 pc 0000687f  /system/lib/lib_omx_player_arm11_elinux.so (_ZN7android9OMXPlayer7prepareEv+626)
11-17 11:21:30.025   162   162 I DEBUG   :     #09 pc 00007d57  /system/lib/lib_omx_player_arm11_elinux.so (_ZN7android9OMXPlayer15ProcessAsyncCmdEv+250)
11-17 11:21:30.025   162   162 I DEBUG   :     #10 pc 00007e67  /system/lib/lib_omx_player_arm11_elinux.so
11-17 11:21:30.025   162   162 I DEBUG   :     #11 pc 00016eb7  /system/lib/libc.so (_ZL15__pthread_startPv+30)
11-17 11:21:30.025   162   162 I DEBUG   :     #12 pc 00014df3  /system/lib/libc.so (__start_thread+6)

[diegoadrian]

Hello,

Can you please, take a look at the bellow community thread. Probably the answer could help you.

https://community.nxp.com/thread/457630 

Best Regards,

Diego.

[hungeason]

Hi,Diego

My source code already include this patch ,but the problem still exist.

Thanks