[Coverity CID :203443]Memory - corruptions in /subsys/bluetooth/host/rfcomm.c

[aasthagr]

Static code scan issues seen in File: /subsys/bluetooth/host/rfcomm.c
Category: Memory - corruptions
Function: bt_rfcomm_dlc_send
Component: Bluetooth
CID: 203443
Please fix or provide comments to square it off in coverity in the link: https://scan9.coverity.com/reports.htm#v32951/p12996
https://scan9.coverity.com/reports.htm#v34747/p12996/

[jhedberg]

There are several things that look messed up with this code. I don't have time to go digging through the RFCOMM spec to figure out what exactly is the right thing. Maybe this is the final straw and we should just remove BR/EDR support from the tree. Downgrading to low priority however since this is considered experimental code.

[joerchan]

@aasthagr Could you possibly check if this issue has been resolved with the fix that was recently submitted to RFCOMM?

[joerchan]

aasthagr Could you possibly check if this issue has been resolved with the fix that was recently submitted to RFCOMM?

Answering my own question. No it does not.

[nashif]

this is marked fixed in coverity with comment

"Source code is not available because it has been purged."

[nashif]

the issue is still there in coverity

[joerchan]

This is intentional, rfcomm has a variable length length field, which is confusing when we cast the uint8_t field to an uint16_t field instead, but the extra byte has been pushed to the net_buf.

@jhedberg I think it would be slighly more correct to make the rfcomm header exclude the length field, and then either push or pull uint8_t or uint16_t from net_buf instead, do you think it is worth it to change it like this?
I don't have any BR/EDR stuff to test any change I would make, so would have to rely on review only I think.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[carlescufi]

@MaureenHelm assigning this to you since @MarkWangChinese is not yet part of the org, and this is BR/EDR with which you've shown an interest in keeping alive.

[MaureenHelm]

@MarkWangChinese can you take a look this week?

[MarkWangChinese]

I created one PR #35706