Bugzilla Bug 102520

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 an attachment (id=65949) [edit]
Fix

Created an attachment (id=65950) [edit]
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