On 11/6/2024 3:53 PM, Bryan O'Donoghue wrote:

On 06/11/2024 07:25, Vikash Garodia wrote:

...

...

...

cap = &caps[core->codecs_count++];            cap->codec = BIT(bit);            cap->domain = VIDC_SESSION_TYPE_ENC;

I don't see how codecs_count could be greater than the control, since you increment by one on each loop but >= is fine too I suppose.

Assume the payload from malicious firmware is packed like below HFI_PROPERTY_PARAM_CODEC_SUPPORTED HFI_PROPERTY_PARAM_CODEC_SUPPORTED HFI_PROPERTY_PARAM_CODEC_SUPPORTED ..... for 32 or more instances of above type

But you do this

cap = &caps[core->codecs_count++];

for each bit.

Yes. Let say that packet is written more than 32 times in the payload response from bad firmware and each has 1 bit set. core->codecs_count would be incremented beyond the allocated space.

Regards, Vikash

Anyway consider Dmitry's input re only calling this function once instead.

---

bod

On 07/11/2024 10:41, Dmitry Baryshkov wrote:

...

init_codecs() parses the payload received from firmware and . I don't think we can control this part when we have something like this from a malicious firmware payload HFI_PROPERTY_PARAM_CODEC_SUPPORTED HFI_PROPERTY_PARAM_CODEC_SUPPORTED HFI_PROPERTY_PARAM_CODEC_SUPPORTED ... Limiting it to second iteration would restrict the functionality when property HFI_PROPERTY_PARAM_CODEC_SUPPORTED is sent for supported number of codecs.

If you can have a malicious firmware (which is owned and signed by Qualcomm / OEM), then you have to be careful and skip duplicates. So instead of just adding new cap to core->caps, you have to go through that array, check that you are not adding a duplicate (and report a [Firmware Bug] for duplicates), check that there is an empty slot, etc.

Just ignoring the "extra" entries is not enough.

+1

This is a more rational argument. If you get a second message, you should surely reinit the whole array i.e. update the array with the new list, as opposed to throwing away the second message because it over-indexes your local storage..

--- bod

On Thu, Nov 07, 2024 at 06:32:33PM +0530, Vikash Garodia wrote:

On 11/7/2024 5:37 PM, Bryan O'Donoghue wrote:

...

On 07/11/2024 10:41, Dmitry Baryshkov wrote:

...

...

init_codecs() parses the payload received from firmware and . I don't think we can control this part when we have something like this from a malicious firmware payload HFI_PROPERTY_PARAM_CODEC_SUPPORTED HFI_PROPERTY_PARAM_CODEC_SUPPORTED HFI_PROPERTY_PARAM_CODEC_SUPPORTED ... Limiting it to second iteration would restrict the functionality when property HFI_PROPERTY_PARAM_CODEC_SUPPORTED is sent for supported number of codecs.

If you can have a malicious firmware (which is owned and signed by Qualcomm / OEM), then you have to be careful and skip duplicates. So instead of just adding new cap to core->caps, you have to go through that array, check that you are not adding a duplicate (and report a [Firmware Bug] for duplicates), check that there is an empty slot, etc.

Just ignoring the "extra" entries is not enough.

Thinking of something like this

for_each_set_bit(bit, &core->dec_codecs, MAX_CODEC_NUM) { if (core->codecs_count >= MAX_CODEC_NUM) return; cap = &caps[core->codecs_count++]; if (cap->codec == BIT(bit)) --> each code would have unique bitfield return;

This won't work and it's pretty obvious why.

...

+1

This is a more rational argument. If you get a second message, you should surely reinit the whole array i.e. update the array with the new list, as opposed to throwing away the second message because it over-indexes your local storage..

That would be incorrect to overwrite the array with new list, whenever new payload is received.

I'd say, don't overwrite the array. Instead the driver should extend it with the new information.

Regards, Vikash

On Thu, Nov 07, 2024 at 07:05:15PM +0530, Vikash Garodia wrote:

On 11/7/2024 6:52 PM, Dmitry Baryshkov wrote:

...

On Thu, Nov 07, 2024 at 06:32:33PM +0530, Vikash Garodia wrote:

...

On 11/7/2024 5:37 PM, Bryan O'Donoghue wrote:

...

On 07/11/2024 10:41, Dmitry Baryshkov wrote:

...

...

init_codecs() parses the payload received from firmware and . I don't think we can control this part when we have something like this from a malicious firmware payload HFI_PROPERTY_PARAM_CODEC_SUPPORTED HFI_PROPERTY_PARAM_CODEC_SUPPORTED HFI_PROPERTY_PARAM_CODEC_SUPPORTED ... Limiting it to second iteration would restrict the functionality when property HFI_PROPERTY_PARAM_CODEC_SUPPORTED is sent for supported number of codecs.

If you can have a malicious firmware (which is owned and signed by Qualcomm / OEM), then you have to be careful and skip duplicates. So instead of just adding new cap to core->caps, you have to go through that array, check that you are not adding a duplicate (and report a [Firmware Bug] for duplicates), check that there is an empty slot, etc.

Just ignoring the "extra" entries is not enough.

Thinking of something like this

for_each_set_bit(bit, &core->dec_codecs, MAX_CODEC_NUM) { if (core->codecs_count >= MAX_CODEC_NUM) return; cap = &caps[core->codecs_count++]; if (cap->codec == BIT(bit)) --> each code would have unique bitfield return;

This won't work and it's pretty obvious why.

Could you please elaborate what would break in above logic ?

After the "cap=&caps[core->codecs_count++]" line 'cap' will point to the new entry, which should not contain valid data.

Instead, when processing new 'bit' you should loop over the existing caps and check that there is no match. And only if there is no match the code should be allocating new entry, checking that codecs_count doesn't overflow, etc.

...

...

...

+1

This is a more rational argument. If you get a second message, you should surely reinit the whole array i.e. update the array with the new list, as opposed to throwing away the second message because it over-indexes your local storage..

That would be incorrect to overwrite the array with new list, whenever new payload is received.

I'd say, don't overwrite the array. Instead the driver should extend it with the new information.

That is exactly the existing patch is currently doing.

_new_ information, not a copy of the existing information.

Regards, Vikash

...

...

Regards, Vikash

On 11/8/2024 5:13 PM, Bryan O'Donoghue wrote:

On 07/11/2024 13:54, Dmitry Baryshkov wrote:

...

...

...

I'd say, don't overwrite the array. Instead the driver should extend it with the new information.

That is exactly the existing patch is currently doing.

_new_ information, not a copy of the existing information.

But is this _really_ new information or is it guarding from "malicious" additional messages ?

@Vikash is it even a valid use-case for firmware to send one set of capabilities and then send a new set ?

It seems to me this should only happen once when the firmware starts up - the firmware won't acquire any new abilities once it has enumerated its set to APSS.

So why is it valid to process an additional message at all ?

Shouldn't we instead be throwing away redundant updates either silently or with some kind of complaint ?

If there's no new data - then this is data we shouldn't bother processing.

If it is new data then surely it should be the _current_ and _only_ valid set of data.

And if the update is considered "invalid" then why _would_ we accept the update ?

I get we're fixing the OOB but I think we should be clear on the validity of the content of the packet.

The payload [1] is all about 2 u32s each for decoder and encoder bit masks, while each bit signifies which codec each supports. So in a good case, it would be always first iteration which would be sufficient. Its a very hypothetical case where a good case would that there are 8 payloads (consider there are 8 supported codecs) with one bit set in each of those 8 payloads. I was initially thinking to cover for this case as well, seems could be a bit of over designing.

Maybe set core->codecs_count (to 0) in the beginning of the API should cover the working case. In malicious case, let it continue to override ?

Regards, Vikash

[1] https://elixir.bootlin.com/linux/v6.12-rc7/source/drivers/media/platform/qco...

On 11/12/2024 5:13 AM, Bryan O'Donoghue wrote:

On 11/11/2024 14:36, Vikash Garodia wrote:

...

...

int hfi_parser(void *buf, int size) {          int word_count = size >> 2;          uint32_t*my_word = (uint32_t*)buf;

Make this as below and it should lead to OOB uint32_t*my_word = (uint32_t*)buf + 1

Regards, Vikash

How does this code make sense ?

while (words_count) {                 data = word + 1;

switch (*word) {                 case HFI_PROPERTY_PARAM_CODEC_SUPPORTED:                         parse_codecs(core, data);                         init_codecs(core);                         break;                 case HFI_PROPERTY_PARAM_MAX_SESSIONS_SUPPORTED:                         parse_max_sessions(core, data);                         break;                 case HFI_PROPERTY_PARAM_CODEC_MASK_SUPPORTED:                         parse_codecs_mask(&codecs, &domain, data);                         break;                 case HFI_PROPERTY_PARAM_UNCOMPRESSED_FORMAT_SUPPORTED:                         parse_raw_formats(core, codecs, domain, data);                         break;                 case HFI_PROPERTY_PARAM_CAPABILITY_SUPPORTED:                         parse_caps(core, codecs, domain, data);                         break;                 case HFI_PROPERTY_PARAM_PROFILE_LEVEL_SUPPORTED:                         parse_profile_level(core, codecs, domain, data);                         break;                 case HFI_PROPERTY_PARAM_BUFFER_ALLOC_MODE_SUPPORTED:                         parse_alloc_mode(core, codecs, domain, data);                         break;                 default:                         break;                 }

word++;                 words_count--;         }

word[] = { 0, 1, 2, 3 };

words_count = 4;

while(words_count);

data = word + 1;

switch(*word) {     case WHATEVER:         do_something(param, data);     }

word++;     words_count--; }

// iteration 0 data = 1; *word = 0;

// iteration 1 data = 2; *word = 1;

????

How can the step size of word be correct ?

Do we ever actually process more than one pair here ?

#include <stdio.h> #include <stdint.h>

char somebuf[16];

void init(char *buf, int len) {         int i;         char c = 0;

for (i = 0; i < len; i++)                 buf[i] = c++; }

int hfi_parser(void *buf, int size) {         int word_count = size >> 2;         uint32_t *my_word = (uint32_t*)buf, *data;

printf("Size %d word_count %d\n", size, word_count);

while (word_count > 1) {                 data = my_word + 1;                 printf("Myword %d == 0x%08x data=0x%08x\n", word_count, *my_word, *data);                 my_word++;                 word_count--;         } }

int main(int argc, char *argv[]) {         int i;

init(somebuf, sizeof(somebuf));         for (i = 0; i < sizeof(somebuf); i++)                 printf("%x = %x\n", i, somebuf[i]);

hfi_parser(somebuf, sizeof(somebuf));

return 0; }

0 = 0 1 = 1 2 = 2 3 = 3 4 = 4 5 = 5 6 = 6 7 = 7 8 = 8 9 = 9 a = a b = b c = c d = d e = e f = f Size 16 word_count 4 Myword 4 == 0x03020100 data=0x07060504 Myword 3 == 0x07060504 data=0x0b0a0908 Myword 2 == 0x0b0a0908 data=0x0f0e0d0c

You did not printed the last iteration without the proposed fix. In the last iteration (Myword 1), it would access the data beyond allocated size of somebuf. So we can see how the fix protects from OOB situation.

For the functionality part, packet from firmware would come as <prop type> followed by <payload for that prop> i.e *word = HFI_PROPERTY_PARAM_CODEC_SUPPORTED *data = payload --> hence here data is pointed to next u32 to point and parse payload for HFI_PROPERTY_PARAM_CODEC_SUPPORTED. likewise for other properties in the same packet

Regards Vikash

On 11/12/2024 4:47 PM, Bryan O'Donoghue wrote:

On 12/11/2024 08:05, Vikash Garodia wrote:

...

You did not printed the last iteration without the proposed fix. In the last iteration (Myword 1), it would access the data beyond allocated size of somebuf. So we can see how the fix protects from OOB situation.

Right but the loop _can't_ be correct. What's the point in fixing an OOB in a loop that doesn't work ?

This is the loop:

#define BUF_SIZE 0x20  // BUF_SIZE doesn't really matter

char somebuf[BUF_SIZE]; u32 *word = somebuf[0]; u32 words = ARRAY_SIZE(somebuf);

while (words > 1) {     data = word + 1;  // this     word++;           // and this     words--; }

On the first loop word = somebuf[0]; data = somebuf[3];

On the second loop word = somebuf[3]; // the same value as *data in the previous loop

and that's just broken because on the second loop *word == *data in the first loop !

That's what my program showed you

word 4 == 0x03020100 data=0x07060504

// word == data from previous loop word 3 == 0x07060504 data=0x0b0a0908

// word == data from previous loop word 2 == 0x0b0a0908 data=0x0f0e0d0c

The step size, the number of bytes this loop increments is fundamentally wrong because

a) Its a fixed size [1] b) *word in loop(n+1) == *data in loop(n)

Which cannot ever parse more than one data item - in effect never loop - in one go.

In the second iteration, the loop would not match with any case and would try to match the case by incrementing word. Let say the first word is "HFI_PROPERTY_PARAM_CODEC_SUPPORTED" followed by 2 words (second and third word) of payload step size. At this point, now when the loop runs again with second word and third word, it would not match any case. Again at 4th word, it would match a case and process the payload. One thing that we can do here is to increment the word count with the step size of the data consumed ? This way 2nd and 3rd iteration can be skipped as we know that there would not be any case in those words.

Regards, Vikash

...

For the functionality part, packet from firmware would come as <prop type> followed by <payload for that prop> i.e *word = HFI_PROPERTY_PARAM_CODEC_SUPPORTED *data = payload --> hence here data is pointed to next u32 to point and parse payload for HFI_PROPERTY_PARAM_CODEC_SUPPORTED. likewise for other properties in the same packet

[1]

But we've established that word increments by one word. We wouldn't fix this loop by just making it into

while (words > 1) {     data = word + 1;     word = data + 1;     words -= 2; }

Because the consumers of the data have different step sizes, different number of bytes they consume for the structs they cast.

=>

case HFI_PROPERTY_PARAM_CODEC_SUPPORTED:     parse_codecs(core, data);     // consumes sizeof(struct hfi_codec_supported)     struct hfi_codec_supported {         u32 dec_codecs;         u32 enc_codecs;     };

case HFI_PROPERTY_PARAM_MAX_SESSIONS_SUPPORTED:     parse_max_sessions(core, data);     // consumes sizeof(struct hfi_max_sessions_supported)     struct hfi_max_sessions_supported {         u32 max_sessions;     };

case HFI_PROPERTY_PARAM_CODEC_MASK_SUPPORTED:     parse_codecs_mask(&codecs, &domain, data);     // consumes sizeof(struct hfi_codec_mask_supported)     struct hfi_codec_mask_supported {             u32 codecs;             u32 video_domains;     };

case HFI_PROPERTY_PARAM_UNCOMPRESSED_FORMAT_SUPPORTED:     parse_raw_formats(core, codecs, domain, data);     // consumes sizeof(struct hfi_uncompressed_format_supported)     struct hfi_uncompressed_format_supported {         u32 buffer_type;         u32 format_entries;         struct hfi_uncompressed_plane_info plane_info;     };

case HFI_PROPERTY_PARAM_CAPABILITY_SUPPORTED:     parse_caps(core, codecs, domain, data);          struct hfi_capabilities {         u32 num_capabilities;         struct hfi_capability data[];     };

where     hfi_platform.h:#define MAX_CAP_ENTRIES        32

I'll stop there.

This routine needs a rewrite.

---

bod