In GetInvInt(int) function, malicious content can access memory
outside of the invCount array. Always bound access to valid
indices.
Test: see bug for malicious content, decoded with "stagefright -s -a"
Bug: 65025048
Change-Id: I92d4a14519f45d5a329d7f69f21f2aef0a8c6daa
In GetInvInt(int) function, malicious content can access memory
outside of the invCount array. Always bound access to valid
indices.
Test: see bug for malicious content, decoded with "stagefright -s -a"
Bug: 65025048
Change-Id: I92d4a14519f45d5a329d7f69f21f2aef0a8c6daa
In GetInvInt(int) function, malicious content can access memory
outside of the invCount array. Always bound access to valid
indices.
Test: see bug for malicious content, decoded with "stagefright -s -a"
Bug: 65025048
Change-Id: I92d4a14519f45d5a329d7f69f21f2aef0a8c6daa
In TRANSPOSER_SETTINGS, initialize the whole bwBorders array to a
reasonable value to guarantee correct termination in while loop
in lppTransposer function. This fixes the reported bug.
For completeness:
- clear the whole bwIndex array instead of noOfPatches entries only.
- abort criterion in while loop to prevent potential
infinite loop, and limit bwIndex[patch] to a valid range.
Test: see bug for malicious content, decoded with "stagefright -s -a"
Bug: 65280786
Change-Id: I16ed2e1c0f1601926239a652ca20a91284151843
In GetInvInt(int) function, malicious content can access memory
outside of the invCount array. Always bound access to valid
indices.
Test: see bug for malicious content, decoded with "stagefright -s -a"
Bug: 65025048
Change-Id: Iff889601828f95b82d9291075f3909922ef533ef
In GetInvInt(int) function, malicious content can access memory
outside of the invCount array. Always bound access to valid
indices.
Test: see bug for malicious content, decoded with "stagefright -s -a"
Bug: 65025048
Change-Id: Id1f1582bc5afc76e3e90128d92034a5899a9b51e
In GetInvInt(int) function, malicious content can access memory
outside of the invCount array. Always bound access to valid
indices.
Test: see bug for malicious content, decoded with "stagefright -s -a"
Bug: 65025048
Change-Id: Iff889601828f95b82d9291075f3909922ef533ef
Bug: 66996870
Test: build with WITH_TIDY=1
Exempt-From-Owner-Approval: Colin +2 should be the owner approval
Change-Id: I167f73ee9dc5e977fd6976f48732ae1e1fe13c8b
Software codecs and their dependencies are marked as VNDK (or just
vendor_available:true for static/header libs).
Bug: 37343418
Test: build the software codecs with BOARD_VNDK_VERSION=current
Change-Id: I9ecedb5a95abc9978ff7ed3538bd2dedec750c7d
Owners are selected from top CL approvals or owners.
They will be suggested to review/approve future CLs.
Test: build/make/tools/checkowners.py -c -v OWNERS
Change-Id: Iacb2e068189b39030a218b6496ca41a0bd4ce7d2
1) Fixes some potential NULL-pointer access in case input pointer is
passed NULL
2) Modified some for lazy init
Test: mm -j 8
Change-Id: I7fca97e1d9f70d8e8c1533b519181af35a5468f7
* In an effort to modernize build configurations to the new Soong
system, we need to upgrade existing Android.mk files to Android.bp
* This file is done by using the following steps:
1. Manually removing all *_sources from Android.mk, because
of the unusual make logic they use
2. Running the auto-conversion tool:
androidmk Android.mk > Android.bp
3. Editing the result Android.bp:
3.1. Writing the "srcs" list
3.2. Removing the escaping around -Wno-#warnings in cflags,
because those are not needed anymore
3.3. Renamed local_include_dirs to export_include_dirs to
facilititate the inclusion of header files.
It appears users of libFraunhoferAAC are using header
files from all include directories, hence the renaming.
Test: Code compilation ("mm" in external/aac, and "make" in top-directory)
Bug: b/32958753 b/34454142
Change-Id: Ie89f73722908e8734f4b88f1407952311ec064af
Clang warns about this being deprecated, when building without specifying
-std=c++98.
This doesn't give any measurable encoding speed impact on ARM or AArch64,
on neither GCC nor Clang.
Change-Id: I63a0bbd1dccb97547522da188ee585d4d8127c29