You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I recently experienced a weird crash when using QtZeroConf on Windows:
I had multiple servers running on my local machine that announced themselves using python's zeroconf implementation. In my C++ client application, I used the zeroconf browser to discover them. While the browser was discovering the servers (more specifically, during parsing of the TXT records of the entries) my application cashed.
I could trace the cause of the crash to the QZeroConfPrivate::resolverCallback function in bonjour.cpp.
While iterating over the txtRecord array it happened that the length of the next record (recLen) was bigger than the total length of the TXT records (txtLen). This resulted in an overflow in this line
I just wanted to get your opinion on this since I'm not really familiar with DNS records: Do you think this behaviour is just a bug in QtZeroConf or could it be that the python zeroconf implementation does something weird with the records it's publishing?
I just would've thought that it could never happen that a TXT record reports that its length (recLen) is 195 but the total length of all TXT records (txtLen) is just 41 or so.
The text was updated successfully, but these errors were encountered:
I recently experienced a weird crash when using QtZeroConf on Windows:
I had multiple servers running on my local machine that announced themselves using python's zeroconf implementation. In my C++ client application, I used the zeroconf browser to discover them. While the browser was discovering the servers (more specifically, during parsing of the TXT records of the entries) my application cashed.
I could trace the cause of the crash to the
QZeroConfPrivate::resolverCallback
function in bonjour.cpp.While iterating over the
txtRecord
array it happened that the length of the next record (recLen
) was bigger than the total length of the TXT records (txtLen
). This resulted in an overflow in this lineQtZeroConf/bonjour.cpp
Line 176 in df4a158
since
txtLen
is anunsigned int
.I could fix the problem by simply adding a check after the
recLen
was read (i.e. after this):QtZeroConf/bonjour.cpp
Line 167 in df4a158
I just wanted to get your opinion on this since I'm not really familiar with DNS records: Do you think this behaviour is just a bug in QtZeroConf or could it be that the python zeroconf implementation does something weird with the records it's publishing?
I just would've thought that it could never happen that a TXT record reports that its length (
recLen
) is 195 but the total length of all TXT records (txtLen
) is just 41 or so.The text was updated successfully, but these errors were encountered: