Win Potential overflow
#1
Hi all,

I was taking a peek at the ISO9660 code and found something quite suspicious:

iso9660.cpp:531 memcpy( &m_info.isodir, m_info.iso.szRootDir, sizeof(m_info.isodir));

szRootDir is only 34 bytes and isodir is of type iso9660_Directory which is 545 bytes.

I would patch it but I don't know the exact intention.

Mike

Reply
#2
Wow this really looks like bullshit. No clue either what was the intention.
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#3
Did you check if its still in use on win32? Windows can read those disc so we could use hdfile here. But I assume that the iso9660 protocol isn't use any more on win and could be removed.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#4
Sorry, that just means I was compiling for windows. I think it's a problem everywhere. I'm trying to figure out how to get xbmc to access an iso.
Reply
#5
Well, it wouldn't overflow 'cause it's only copying the correct number of bytes over.
IF the code is being used, my guess is that nobody's noticed because the members referenced in the copy (after the memcpy) are luckily in the first 32 bytes...
Reply
#6
edrikk it would overflow the source buffer ... not the destination ... well not overflow - but bad access...
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#7
Your absolutely correct.
Reply

Logout Mark Read Team Forum Stats Members Help
Potential overflow0