I've found and identified a bug in file which causes it to read beyond the end of a buffer. Not sure if this is a security issue (as its only a 'read overflow') but I thought I should check with you first. mget() in softmagic.c will perform a memcpy operation and in some circumstances will attempt to read beyond the end of the source buffer. It does do *some* bounds checking but in the case of FILE_SEARCH this is wrong. (approx line 1125) case FILE_STRING: case FILE_PSTRING: case FILE_SEARCH: if (nbytes < (offset + m->vallen)) return 0; (approx line 1135) if (m->type == FILE_SEARCH) { p->buf = malloc(m->mask + m->vallen); if (p->buf == NULL) { file_error(ms, errno, "Cannot allocate search buffer"); return 0; } (void)memcpy(p->buf, s + offset, m->mask + m->vallen); } You can see it will read mask+vallen bytes starting at s+offset. However there is no check that s+offset+mask+vallen (i.e. the end of the data being copied) is still within the bounds of s. 'nbytes' refers to the size of s.
Created attachment 65949 [details, diff] Fix
Created attachment 65950 [details, diff] Sample file This file will cause the read overflow. An unpatched file-4.14 tries to read 12292 bytes starting at offset 255488 from s. s is just an in-memory copy of this file, 256000 bytes, so it obviously goes much too far. Even without the patch, file still happily works on this on my x86. However on amd64 it seems much easier to reproduce - you get a Segmentation fault.
*** Bug 102504 has been marked as a duplicate of this bug. ***
Does not appear to be any security impact, reassigning to base-system.
Sent patch upstream
Upstream maintainer confirms the problem and says it exists in other places too. Expect a 4.15 release soon.
file-4.15 now in portage
