RFE: group all audit task parameters together #81
Assignees
Labels
Comments
|
Paul, please assign to me...
|
|
@rgbriggs it might be nice to provide a link to the mailing list discussion for this, or at the very least copy-n-past the relevant portions here. |
|
On 2018-04-25 11:28, Paul Moore wrote:
@rgbriggs it might be nice to provide a link to the mailing list discussion for this, or at the very least copy-n-past the relevant portions here.
See discussion started here:
https://www.redhat.com/archives/linux-audit/2018-April/msg00055.html
and continuing here:
https://www.redhat.com/archives/linux-audit/2018-April/msg00094.html
|
|
2018-05-04: Posted v1 patchset (static alloc) 2018-05-12: Posted v2 patchset (static alloc) 2018-05-14: Merged upstream: 2018-05-16: Posted v3 patchset (dynamic alloc) |
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
May 17, 2018
The audit-related parameters in struct task_struct should ideally be collected together and accessed through a standard audit API. Collect the existing loginuid, sessionid and audit_context together in a new struct audit_task_info called "audit" in struct task_struct. Use kmem_cache to manage this pool of memory. Un-inline audit_free() to be able to always recover that memory. See: linux-audit/audit-kernel#81 Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
|
Reposted with ghak90 (was ghak32:contid) upstream: |
|
As discussed on the mailing list, this is really only going to go in with the audit container ID work so let's close this out and just use issue #90 since this issue doesn't make sense by itself any longer. |
fcicq
pushed a commit
to fcicq/chromiumos-third_party-kernel
that referenced
this issue
Jan 18, 2019
The audit-related parameters in struct task_struct should ideally be collected together and accessed through a standard audit API. Collect the existing loginuid, sessionid and audit_context together in a new struct audit_task_info called "audit" in struct task_struct. Use kmem_cache to manage this pool of memory. Un-inline audit_free() to be able to always recover that memory. See: linux-audit/audit-kernel#81 Signed-off-by: Richard Guy Briggs <rgb@redhat.com> (am from https://patchwork.kernel.org/patch/10556033/) BUG=chromium:918980 TEST=Build, boot and GCP internal testing. This change is needed to add container identifier to task_struct. It was changed to handle the differences on how the task structure is initialized. In 4.14, the the initialization is done in init_task.h instead of init_task.c. Signed-off-by: Thomas Garnier <thgarnie@google.com> Change-Id: I42f5dead5c50df2bdb6774862613f53894b1a221 Reviewed-on: https://chromium-review.googlesource.com/1379654 Reviewed-by: Dmitry Torokhov <dtor@chromium.org> Reviewed-by: Robert Kolchmeyer <rkolchmeyer@google.com> Reviewed-by: Kees Cook <keescook@chromium.org>
fcicq
pushed a commit
to fcicq/chromiumos-third_party-kernel
that referenced
this issue
Jun 26, 2019
The audit-related parameters in struct task_struct should ideally be collected together and accessed through a standard audit API. Collect the existing loginuid, sessionid and audit_context together in a new struct audit_task_info called "audit" in struct task_struct. Use kmem_cache to manage this pool of memory. Un-inline audit_free() to be able to always recover that memory. Please see the upstream github issue linux-audit/audit-kernel#81 Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Richard Guy Briggs <rgb@redhat.com> (am from https://patchwork.kernel.org/patch/10890457/) BUG=b/131183634 TEST=Build, boot and GCP internal testing. This change was modified to support 4.19. In particular: - audit_take_context was still relaying on tsk->audit_context. - audit_free_syscall was not checking if the context was NULL. - audit_set_loginuid was accessing sessionid and loginuid in the task instead of through the audit pointer. Signed-off-by: Thomas Garnier <thgarnie@google.com> Change-Id: I7ec707447994bb502a4fb011ed5dd7ca2fed579a Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1674487 Reviewed-by: Guenter Roeck <groeck@chromium.org> Tested-by: Thomas Garnier <thgarnie@chromium.org> Commit-Queue: Thomas Garnier <thgarnie@chromium.org>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Jan 3, 2020
The audit-related parameters in struct task_struct should ideally be collected together and accessed through a standard audit API. Collect the existing loginuid, sessionid and audit_context together in a new struct audit_task_info called "audit" in struct task_struct. Use kmem_cache to manage this pool of memory. Un-inline audit_free() to be able to always recover that memory. Please see the upstream github issue linux-audit/audit-kernel#81 Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Jun 27, 2020
The audit-related parameters in struct task_struct should ideally be collected together and accessed through a standard audit API. Collect the existing loginuid, sessionid and audit_context together in a new struct audit_task_info called "audit" in struct task_struct. Use kmem_cache to manage this pool of memory. Un-inline audit_free() to be able to always recover that memory. Please see the upstream github issue linux-audit/audit-kernel#81 Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Dec 22, 2020
The audit-related parameters in struct task_struct should ideally be collected together and accessed through a standard audit API and the audit structures made opaque to other kernel subsystems. Collect the existing loginuid, sessionid and audit_context together in a new opaque struct audit_task_info called "audit" in struct task_struct. Use kmem_cache to manage this pool of memory. Un-inline audit_free() to be able to always recover that memory. Please see the upstream github issues linux-audit/audit-kernel#81 linux-audit/audit-kernel#90 Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Jan 12, 2021
The audit-related parameters in struct task_struct should ideally be collected together and accessed through a standard audit API and the audit structures made opaque to other kernel subsystems. Collect the existing loginuid, sessionid and audit_context together in a new opaque struct audit_task_info called "audit" in struct task_struct. Use kmem_cache to manage this pool of memory. Un-inline audit_free() to be able to always recover that memory. Please see the upstream github issues linux-audit/audit-kernel#81 linux-audit/audit-kernel#90 Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
pcmoore
pushed a commit
that referenced
this issue
Oct 3, 2022
During our testing of WFM200 module over SDIO on i.MX6Q-based platform, we discovered a memory corruption on the system, tracing back to the wfx driver. Using kfence, it was possible to trace it back to the root cause, which is hw->max_rates set to 8 in wfx_init_common, while the maximum defined by IEEE80211_TX_TABLE_SIZE is 4. This causes array out-of-bounds writes during updates of the rate table, as seen below: BUG: KFENCE: memory corruption in kfree_rcu_work+0x320/0x36c Corrupted memory at 0xe0a4ffe0 [ 0x03 0x03 0x03 0x03 0x01 0x00 0x00 0x02 0x02 0x02 0x09 0x00 0x21 0xbb 0xbb 0xbb ] (in kfence-#81): kfree_rcu_work+0x320/0x36c process_one_work+0x3ec/0x920 worker_thread+0x60/0x7a4 kthread+0x174/0x1b4 ret_from_fork+0x14/0x2c 0x0 kfence-#81: 0xe0a4ffc0-0xe0a4ffdf, size=32, cache=kmalloc-64 allocated by task 297 on cpu 0 at 631.039555s: minstrel_ht_update_rates+0x38/0x2b0 [mac80211] rate_control_tx_status+0xb4/0x148 [mac80211] ieee80211_tx_status_ext+0x364/0x1030 [mac80211] ieee80211_tx_status+0xe0/0x118 [mac80211] ieee80211_tasklet_handler+0xb0/0xe0 [mac80211] tasklet_action_common.constprop.0+0x11c/0x148 __do_softirq+0x1a4/0x61c irq_exit+0xcc/0x104 call_with_stack+0x18/0x20 __irq_svc+0x80/0xb0 wq_worker_sleeping+0x10/0x100 wq_worker_sleeping+0x10/0x100 schedule+0x50/0xe0 schedule_timeout+0x2e0/0x474 wait_for_completion+0xdc/0x1ec mmc_wait_for_req_done+0xc4/0xf8 mmc_io_rw_extended+0x3b4/0x4ec sdio_io_rw_ext_helper+0x290/0x384 sdio_memcpy_toio+0x30/0x38 wfx_sdio_copy_to_io+0x88/0x108 [wfx] wfx_data_write+0x88/0x1f0 [wfx] bh_work+0x1c8/0xcc0 [wfx] process_one_work+0x3ec/0x920 worker_thread+0x60/0x7a4 kthread+0x174/0x1b4 ret_from_fork+0x14/0x2c 0x0 After discussion on the wireless mailing list it was clarified that the issue has been introduced by: commit ee0e16a ("mac80211: minstrel_ht: fill all requested rates") and fix shall be in minstrel_ht_update_rates in rc80211_minstrel_ht.c. Fixes: ee0e16a ("mac80211: minstrel_ht: fill all requested rates") Link: https://lore.kernel.org/all/12e5adcd-8aed-f0f7-70cc-4fb7b656b829@camlingroup.com/ Link: https://lore.kernel.org/linux-wireless/20220915131445.30600-1-lech.perczak@camlingroup.com/ Cc: Jérôme Pouiller <jerome.pouiller@silabs.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Peter Seiderer <ps.report@gmx.net> Cc: Kalle Valo <kvalo@kernel.org> Cc: Krzysztof Drobiński <krzysztof.drobinski@camlingroup.com>, Signed-off-by: Paweł Lenkow <pawel.lenkow@camlingroup.com> Signed-off-by: Lech Perczak <lech.perczak@camlingroup.com> Reviewed-by: Peter Seiderer <ps.report@gmx.net> Reviewed-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Acked-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Move all audit-related task parameters out of struct task_struct into a dedicated structure allocated at task creation. At the moment this includes loginuid, sessionid and audit_context.
The text was updated successfully, but these errors were encountered: