> On Mon, 17 Jul 2017, Elena Reshetova wrote:
>
> > Subject: kernel: convert futex_pi_state.refcount from atomic_t to refcount_t
>
> Several people including myself told you already, that subjects consist of
>
> SUBSYSTEMPREFIX: Concise description
>
> It's easy enough to figure the prefix out
I got following memory leak reports by kmemleak.
unreferenced object 0x965962fa0600 (size 256):
comm "auditd", pid 401, jiffies 4294671604 (age 62.331s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
I hope that someone can help me with accomplishing this list of AUDIT goals.
--
Warron French
On Fri, Jul 14, 2017 at 6:03 PM, warron.french
wrote:
> This may be faster and also a better way to summarize and share with
> others.
> I will list the AUDIT(test#letter) and
On Friday, July 14, 2017 5:18:13 PM EDT warron.french wrote:
> OK, so no rules to be found specifically/explicitly in audit.rules (for
> RHEL6 nor RHEL7) because it is hardwired/embedded in the code of auditd
> already?
Not auditd. In whatever observes the event. Pam observes the login for sshd
a
On Mon, 17 Jul 2017, Elena Reshetova wrote:
> Subject: kernel: convert futex_pi_state.refcount from atomic_t to refcount_t
Several people including myself told you already, that subjects consist of
SUBSYSTEMPREFIX: Concise description
It's easy enough to figure the prefix out by looking at the
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
Changes in v3:
* SoB chain corrected
* minor corrections based on v2 feedback
* rebase on linux-next/master as of today
Changes in v2:
* dropped already merged patches
* rebase on top of linux-next/master
* Now by default refcount_t = atomic_t (*) and uses all atomic
standard operations u
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
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.
Suggested-by: Kees Cook
Reviewed-by: David Windsor
Reviewed-by: Hans Lilje
21 matches
Mail list logo