- 06 Apr, 2016 40 commits
-
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
aa_label_remove needs to take the ls write lock but, we are already holding it so move to __aa_label_remove also fix bug where the old label is not being forwarded to the new label when it results in a new namespace due to an the old ns being removed. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1482943 apparmor use kern_path() to lookup the path of the dev_name, and when this fails apparmor emits a DENIED log message. However for bind and move mounts the underlying code does a call to kern_path() regardless of apparmor being present and so has the same failure. In these cases when kern_path() fails apparmor is not responsible for the mount failure as the kernel will fail the mount regarless of apparmor's presence, so just return the error and don't log an apparmor audit message. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
fixup of [20/23] apparmor: Fix: refcount bug when inserting label update that transitions ns may want to split into 2 patches Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
File permissions have not been updated to use the newer compute_perms fn yet. So export the fn to compute the file permissions and use it in query_label until file permissions have been converted. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Double calling remove on a label does a double update of the replacedby which is extra work and messes up tracking stats. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
There are a few cases when racing an update where a label can be allocated with its replacedby, and end up being freed directly because it lost the race and will not be used. However without breaking the circular ref between the label and its replacedby, a double free of the label will occur: label being freed ref count from label to replacedby is put, ref count from replacedby is put label is scheduled to be freed replacedby is freed label is freed rcu call back to free label triggers label is freed again Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
We already have a refcount on l, and aa_label_insert() returns another refcount so we need to make sure to put the extra one. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
UBUNTU: SAUCE: apparmor: Fix: now that insert can force replacement use it instead of remove_and_insert Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
pivotroot medition may change the tasks current cred if the a transition rule is defined. However aa_begin_current_label(), and aa_end_current_label() define a critical section block where the tasks cred label are not allowed to be updated. Specifically they do not take a refcount on the tasks cred, but will return a refcounted label IF there is an updated version of the label that can not be immediately updated. The aa_end_current_label() fn detects whether the label used has a refcount to put by comparing the label to the task's cred label, and if its different putting label. When the task cred's label is changed within this critical section, the cred update will put the creds label reference, and then the aa_begin_current_label() fn will detect the difference in the cred and working label and subsequentially do an extra put on the label. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
don't put the reference when sharing a replacedby until after all over references are gotten, otherwise the label might drop to a 0 refcount and start being freed, even though it should be held by the shared replacedby. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 The allocation of a replacedby in the label merge path needs to be done using GFP_ATOMIC. specifically aa_label_merge() is called from a context in file.c that passes GFP_ATOMIC to aa_label_merge() which then is doing GFP_KERNEL for the replacedby allocation. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 replacedby updates must be able to occur when in an rcu critical sections, and when spin locks are held. As such it can not use a mutex lock to protect its critical section. Since replacedby updates are accompanied by labelset insertion and removals use the labelset write lock to protect the update critical section. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 __aa_update_replacedby needs the ns lock held, this is done for profile load/replace/remove case and the label_update case but not when called from the label merge paths. NOTE: this is just a conceptal "fix", it can not be validly used as label_merge is called from atomic context and taking a mutex_lock may sleep. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 When aa_put_label() is called from a fn that is holding the labelset lock, it can result in a deadlock if the put count reaches 0 triggering the kref callback, which tries to take the label set lock. Rework so the label_kref callback deferrs removing the label from the labelset until the rcu callback, ensuring the lock is not held by the calling code. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 label_vec_merge should only do the insertion after the vector is copied. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 Basic profile labels always have a replacedby allocated and set but the code used to create labels from merges without a replacedby and let label_update allocate and set those labels replacedby structs. While the label_merge fix addressed the race between label_merge and label_update, it still left a bug where labels from merges race label_update so that they remain permanently stale, because they don't have proper replacedby information that should be updated during their replacement. Specifically a label from a merge will not have a replacedby if it has never been through a label_update cycle, and the direct replacement from the label_merge fix is NOT updating the replacedby to avoid doing allocations under lock. This results in the old label being permanently diconnected and its references never updating correctly. To fix this create all labels that result from a merge with a replacedby. This results in all labels inserted into the labelset having valid replacedby structs. In the case that the insertion of a label results in a replacement due to it creating an updated version of the label, the old labels replacedby will be reused and the new one can be freed. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
if aa_label_alloc() fails the refs taken on a and b are leaked. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 The labelset does not hold a refcount on the labels its contains, all lookups are done under lock. However in the window between finding a label in the labelset and getting its reference, where the last label reference can be put causing the label to begin its cleanup. Ensure the any label in the set has valid reference before returning its reference. We do this by getting its reference and failing on that reference if the label has begun cleanup. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 Fix a couple of bugs in label merge. - the unconfined status may not be correctly set in the case of a stale profile - if merge(A,B) == A' where A' is revised none stale version of A then the insertion of A' to replace A can fail. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
And label and replacedby reference poisoning to make catching and debugging label refcount errors easier. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
UBUNTU: SAUCE: apparmor: Fix: ensure aa_get_newest will trip debugging if the replacedby is not setup BugLink: http://bugs.launchpad.net/bugs/1448912 While we are at it, also catch any potential refcounting errors arround the replacedby label dereference. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1448912 it is possible for a label_merge to be racing label_update resulting in the AA_BUG(__aa_label_remove_and_insert()) to trip. Instead check if a version of label has already been inserted and gracefully fail if label_update lost the race. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1430546 The profile update mechanism can return a stale label when an update to the task's cred fails. Fix this so that the current label is always returned. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1430546Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Passing NULL ns to label print fns is used as shorthand in the a few places to mean default to the current ns (ie. aa_current_ns()). However not all the print routines support this. Instead of fixing the call sites that pass null into the label_print fns, update all the label_print fns to support this use. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
John Johansen authored
This is a patch to an apparmor feature that is not currently upstream BugLink: http://bugs.launchpad.net/bugs/1539349 Commit 08518549 made it so kern_path() via getname_kernel() may do a GFP_KERNEL based allocation which is causing the "sleep from invalid context" lockdep warning. Rework The apparmor mount code to move kern_path() calls outside of the get_buffers()/put_buffers() RCU read_lock block. Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Andy Whitcroft authored
Signed-off-by: Andy Whitcroft <apw@canonical.com>
-
Andy Whitcroft authored
Signed-off-by: Andy Whitcroft <apw@canonical.com>
-
Colin Ian King authored
In the unlikely event that regno == nr_registers then we get an array overrun on regoff because the invalid register check is currently off-by-one. Fix this with a check that regno is >= nr_registers instead. Detected with static analysis using CoverityScan. Fixes: fcc7ffd6 "x86, mpx: Decode MPX instruction to get bound violation information" Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1456512931-3388-1-git-send-email-colin.king@canonical.comSigned-off-by: Thomas Gleixner <tglx@linutronix.de> (cherry picked from commit 9bf148cb) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Martin Schwidefsky authored
BugLink: http://bugs.launchpad.net/bugs/1550468 git commit 80703617 "s390: add support for vector extension" broke 31-bit compat processes in regard to signal handling. The restore_sigregs_ext32() function is used to restore the additional elements from the user space signal frame. Among the additional elements are the upper registers halves for 64-bit register support for 31-bit processes. The copy_from_user that is used to retrieve the high-gprs array from the user stack uses an incorrect length, 8 bytes instead of 64 bytes. This causes incorrect upper register halves to get loaded. Cc: stable@vger.kernel.org # 3.8+ Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit 342300cc) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Andy Lutomirski authored
BugLink: http://bugs.launchpad.net/bugs/1550517 This doesn't seem to fix a regression -- I don't think the CLAC was ever there. I double-checked in a debugger: entries through the int80 gate do not automatically clear AC. Stable maintainers: I can provide a backport to 4.3 and earlier if needed. This needs to be backported all the way to 3.10. Reported-by: Brian Gerst <brgerst@gmail.com> Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@vger.kernel.org> # v3.10 and later Fixes: 63bcff2a ("x86, smap: Add STAC and CLAC instructions to control user space access") Link: http://lkml.kernel.org/r/b02b7e71ae54074be01fc171cbd4b72517055c0e.1456345086.git.luto@kernel.orgSigned-off-by: Ingo Molnar <mingo@kernel.org> (cherry picked from commit 3d44d51b) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Martin Schwidefsky authored
BugLink: http://bugs.launchpad.net/bugs/1548414 git commit 904818e2 "s390/kernel: introduce fpu-internal.h with fpu helper functions" introduced the fpregs_store / fp_regs_load helper. These function fail to save and restore the floating pointer control registers. The effect is that the FPC is not correctly handled on signal delivery and signal return. Cc: stable@vger.kernel.org # 4.4 Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit 1b17cb79) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Paolo Bonzini authored
BugLink: http://bugs.launchpad.net/bugs/1550596 Commit e8dd2d2d ("Silence compiler warning in arch/x86/kvm/emulate.c", 2015-09-06) broke boot of the Hurd. The bug is that the "default:" case actually could modify "la", but after the patch this change is not reflected in *linear. The bug is visible whenever a non-zero segment base causes the linear address to wrap around the 4GB mark. Fixes: e8dd2d2d Cc: stable@vger.kernel.org Reported-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 0c1d77f4) Signed-off-by: Colin King <colin.king@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1532914 The PSL timebase synchronization is seemingly failing for configuration not including VIRT_CPU_ACCOUNTING_NATIVE. The driver shows the following trace in dmesg: PSL: Timebase sync: giving up! The PSL timebase register is actually syncing correctly, but the cxl driver is not detecting it. Fix is to use the proper timebase-to-time conversion. Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Cc: <stable@vger.kernel.org> # 4.3+ Acked-by: Michael Neuling <mikey@neuling.org> Reviewed-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Acked-by: Ian Munsie <imunsie@au1.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> (cherry picked from git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git commit 923adb16) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
-