On 17 Jun 2014 18:22, "Kenneth Westerback" wrote:
>
> On 17 June 2014 17:43, Tobias Stoeckmann wrote:
> > On Mon, Jun 16, 2014 at 04:43:02PM -0700, John-Mark Gurney wrote:
> >> FreeBSD fixed this by increasing the malloc size:
> >> https://svnweb.freebsd.org/changeset/base/r126086
> >
> > Which i
On 17 June 2014 17:43, Tobias Stoeckmann wrote:
> On Mon, Jun 16, 2014 at 04:43:02PM -0700, John-Mark Gurney wrote:
>> FreeBSD fixed this by increasing the malloc size:
>> https://svnweb.freebsd.org/changeset/base/r126086
>
> Which is actually the correct way to do here!
>
> pmp->pm_maxcluster is
On Mon, Jun 16, 2014 at 04:43:02PM -0700, John-Mark Gurney wrote:
> FreeBSD fixed this by increasing the malloc size:
> https://svnweb.freebsd.org/changeset/base/r126086
Which is actually the correct way to do here!
pmp->pm_maxcluster is the largest valid _index_ of pmp->pm_inusemap,
therefore we
Tobias Stoeckmann wrote this message on Tue, Jun 17, 2014 at 00:05 +0200:
> there is a potential off by one in function fillinusemap() leading to
> possible out of boundary access (32 bytes after allocated area).
>
> pmp->pm_inusemap is allocated in msdosfs_vfsops.c like this:
>
> bmapsiz = (
Hi,
there is a potential off by one in function fillinusemap() leading to
possible out of boundary access (32 bytes after allocated area).
pmp->pm_inusemap is allocated in msdosfs_vfsops.c like this:
bmapsiz = (pmp->pm_maxcluster + N_INUSEBITS - 1) / N_INUSEBITS;
pmp->pm_inusemap = mallo