[Security] Potential Buffer Overflow in DRM Mode (Theoretical)

[BreakingBad6]

I've identified two potential buffer overflow vulnerabilities in FAAD2's DRM (Digital Radio Mondiale) mode through static analysis. However, as a pwn/exploitation researcher without deep AAC codec knowledge, I'm unable to fully verify these vulnerabilities with practical exploits.
Location: libfaad/syntax.c:1297 (DRM_aac_scalable_main_element) and libfaad/hcr.c:296 (reordered_spectral_data)

• Type: Out-of-bounds write in spectral data arrays
• Severity: High (theoretical)

• Root Cause

In DRM_aac_scalable_main_element:

ALIGN int16_t spec_data1[1024] = {0};  // Fixed size array
ALIGN int16_t spec_data2[1024] = {0};
// Line 1384: Potential overflow
if ((hInfo->error = reordered_spectral_data(hDecoder, ics1, ld, spec_data1)) > 0)

In reordered_spectral_data (hcr.c:296):

uint16_t sp = sp_offset[g] + ics->sect_sfb_offset[g][sfb] + inc * (cws + w_idx*group_cws_count);
// Line 307: sp used as array index without bounds check
huffman_spectral_data_2(this_sec_CB, &segment[numberOfSegments], &spectral_data[sp]);

Key Finding: CRC Does Not Cover Spectral Data

I verified that the CRC check (syntax.c:1377) occurs before spectral data is read:

// Line 1377: CRC check
if ((hInfo->error = (uint8_t)faad_check_CRC(ld, (uint16_t)faad_get_processed_bits(ld) - 8)) > 0)
    return;
// Line 1384: Spectral data read AFTER CRC check
if ((hInfo->error = reordered_spectral_data(hDecoder, ics1, ld, spec_data1)) > 0)

Inside reordered_spectral_data, new data is read via faad_getbits() (hcr.c:193-198), which is not covered by the CRC check.
This means an attacker could craft a DRM packet with:

• Valid header (passes CRC check)
• Malicious spectral data (triggers overflow)
  However,I'm a pwn researcher, not an audio codec expert,not an reverse resercher.I don't have deep knowledge of AAC/DRM packet structure.I only have GDB (Linux), not IDA/Windows debugging experience.Simple test data (all zeros) doesn't trigger the overflow.The vulnerability likely requires specific ics structure values to trigger.

Questions for Developers

1. Is this a valid security concern?

   • Can malicious ics->sect_sfb_offset or num_swb values cause sp to exceed 1024?

2. What are the valid ranges for these fields?

   • ics->num_window_groups
   • ics->sect_sfb_offset[g][sfb]
   • sp_offset[g]

3. Are there existing bounds checks I missed?

   • I see checks at hcr.c:230-238, but they seem insufficient

4. Can you provide a sample DRM AAC packet?

   • This would help me construct a proper test case
     The questions are:DRM usage is relatively limited.Requires specific packet structure to trigger.May be a false positive if bounds checks exist elsewhere.
     As I lack the AAC codec expertise to fully verify this, I'm reporting it as a theoretical vulnerability for your review.
     Could you:

5. Review the code paths I identified

6. Confirm if bounds checking is sufficient

7. Provide guidance on constructing a valid test case

8. I'm happy to continue testing if you can provide sample DRM packets or guidance on the expected data structure.