libsepol CVE patch issue

libsepol CVE patch issue

[Garrett Tucker]

Hi everyone, I'm a product security engineer at Red Hat and we noticed
that libsepol CVE-2021-36087 was assigned, and marked as resolved
within the OSS-Fuzz project. The patch info provided for the CVE
appears to be wrong, and after looking into the provided commits and
commit ranges, these seem to be the wrong commits and commit ranges
for this CVE.

Would anyone be able to confirm if there is a fix for this CVE, and if
so, point us towards the correct patch for this.

All the best,

Garrett

Re: libsepol CVE patch issue

[James Carter]

On Fri, Jul 23, 2021 at 11:43 AM Garrett Tucker <gtucker@redhat.com> wrote:
>
> Hi everyone, I'm a product security engineer at Red Hat and we noticed
> that libsepol CVE-2021-36087 was assigned, and marked as resolved
> within the OSS-Fuzz project. The patch info provided for the CVE
> appears to be wrong, and after looking into the provided commits and
> commit ranges, these seem to be the wrong commits and commit ranges
> for this CVE.
>
> Would anyone be able to confirm if there is a fix for this CVE, and if
> so, point us towards the correct patch for this.
>

It is very hard to figure out what is going on in the policy provided
by the fuzzer. The best I can figure out is that the problem was
caused by something in an optional block that had been disabled and
deleted being referred to outside of the optional block. Removing all
of the optional blocks that are going to be disabled anyway eliminates
the problem, so that seems to confirm that idea.

This commit prevents that whole class of bugs from occurring.
340f0eb7f3673e8aacaf0a96cbfcd4d12a405521
libsepol/cil: Check for statements not allowed in optional blocks

The problem is definitely there before this patch. After this patch an
error is produced because a block is declared in an optional.

I hope that helps,
Jim


> All the best,
>
> Garrett
>

Re: libsepol CVE patch issue

[Garrett Tucker]

Thanks for the detailed explanation Jim, that definitely helps clear
things up on our end.

All the best,

Garrett

On Fri, Jul 23, 2021 at 1:18 PM James Carter <jwcart2@gmail.com> wrote:
>
> On Fri, Jul 23, 2021 at 11:43 AM Garrett Tucker <gtucker@redhat.com> wrote:
> >
> > Hi everyone, I'm a product security engineer at Red Hat and we noticed
> > that libsepol CVE-2021-36087 was assigned, and marked as resolved
> > within the OSS-Fuzz project. The patch info provided for the CVE
> > appears to be wrong, and after looking into the provided commits and
> > commit ranges, these seem to be the wrong commits and commit ranges
> > for this CVE.
> >
> > Would anyone be able to confirm if there is a fix for this CVE, and if
> > so, point us towards the correct patch for this.
> >
>
> It is very hard to figure out what is going on in the policy provided
> by the fuzzer. The best I can figure out is that the problem was
> caused by something in an optional block that had been disabled and
> deleted being referred to outside of the optional block. Removing all
> of the optional blocks that are going to be disabled anyway eliminates
> the problem, so that seems to confirm that idea.
>
> This commit prevents that whole class of bugs from occurring.
> 340f0eb7f3673e8aacaf0a96cbfcd4d12a405521
> libsepol/cil: Check for statements not allowed in optional blocks
>
> The problem is definitely there before this patch. After this patch an
> error is produced because a block is declared in an optional.
>
> I hope that helps,
> Jim
>
>
> > All the best,
> >
> > Garrett
> >
>