Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed Issue #147. #154

Merged
merged 2 commits into from
Jul 16, 2012
Merged

Fixed Issue #147. #154

merged 2 commits into from
Jul 16, 2012

Conversation

grefab
Copy link
Contributor

@grefab grefab commented Jul 15, 2012

When requesting resend of packets a lot, iOS sometimes sends a packet with type 0x56 (Reply to resend request), but with sequence number 0 and length == 4. This short length leads to memory corruption later on when processing the packet: alac_decode() expects at least 16 bytes for AES IV. Therefore the segfault.

This fix ignores packets with length < 16, as seen in another implementation here:
http://fossies.org/dox/mythtv-0.25.1/mythraopconnection_8cpp_source.html#l00555

Please be aware that this just fixes the segfault. The suspicious packet seems to be an information of an out of sync situation, so it may deserve further attention.

Signed-off-by: Gregor Fabritius gre@g0r.de

grefab added 2 commits July 15, 2012 23:10
When requesting resend of packets a lot, iOS sometimes sends a packet with type 0x56 (Reply to resend request), but with sequence number 0 and length == 4. This short length leads to memory corruption later on when processing the packet: alac_decode() expects at least 16 bytes for AES IV. Therefore the segfault.

This fix ignores packets with length < 16, as seen in another implementation here:
http://fossies.org/dox/mythtv-0.25.1/mythraopconnection_8cpp_source.html#l00555

Please be aware that this just fixes the segfault. The suspicious packet seems to be an information of an out of sync situation, so it may deserve further attention.

Signed-off-by: Gregor Fabritius <gre@g0r.de>
The packet type 0x56, sequence number 0, containing 4 bytes (the first two are the sequence number of the previously requested packet) initiates a resync. Not sure what this packet is supposed to do, but it occurs after heavy requesting resending of packets. Seems to be an out of sync situation, so resyncing is not the worst idea.

Signed-off-by: Gregor Fabritius <gre@g0r.de>
abrasive pushed a commit that referenced this pull request Jul 16, 2012
@abrasive abrasive merged commit 7df1fa7 into abrasive:master Jul 16, 2012
@abrasive
Copy link
Owner

Thanks for the patch!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants