On Tue, Feb 21, 2017 at 2:15 AM, Reshetova, Elena
<elena.reshetova(a)intel.com> wrote:
> On Mon, Feb 20, 2017 at 5:19 AM, Elena Reshetova
> <elena.reshetova(a)intel.com> wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova <elena.reshetova(a)intel.com>
> > Signed-off-by: Hans Liljestrand <ishkamiel(a)gmail.com>
> > Signed-off-by: Kees Cook <keescook(a)chromium.org>
> > Signed-off-by: David Windsor <dwindsor(a)gmail.com>
> > ---
> > kernel/audit_tree.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
>
> No objection on my end, same for patch 16/19.
>
> I have no problem merging both these patches into the audit/next
> branch after the merge window, is that your goal or are you merging
> these via a different tree?
Thank you Paul! I think it is better if they go through the trees they supposed to go
through
since this way they would get more testing and etc. So, please take the relevant ones to
your tree when the time is right.
After the first round, I guess we will see what patches are not propagating and then
maybe take them via Kees tree.
I just realized that include/linux/refcount.h didn't make it into
v4.10 which means there is going to be delay until I merge them into
the audit tree (I don't base the tree on -rc releases except under
extreme circumstances). I've got the patches queued up in a private
holding branch (I added #includes BTW) so I won't forget, but as a
FYI, they likely won't make it in until v4.12.
--
paul moore
www.paul-moore.com