| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
apparmor: validate DFA start states are in bounds in unpack_pdb mainline inclusion from mainline-v7.0-rc4 commit 9063d7e2615f4a7ab321de6b520e23d370e58816 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13880 CVE: CVE-2026-23269 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9063d7e2615f4a7ab321de6b520e23d370e58816 -------------------------------- Start states are read from untrusted data and used as indexes into the DFA state tables. The aa_dfa_next() function call in unpack_pdb() will access dfa->tables[YYTD_ID_BASE][start], and if the start state exceeds the number of states in the DFA, this results in an out-of-bound read. ================================================================== BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360 Read of size 4 at addr ffff88811956fb90 by task su/1097 ... Reject policies with out-of-bounds start states during unpacking to prevent the issue. Fixes: ad5ff3db53c6 ("AppArmor: Add ability to load extended policy") Reported-by: Qualys Security Advisory <qsa@qualys.com> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Reviewed-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: Massimiliano Pellizzer <massimiliano.pellizzer@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com> Conflicts: security/apparmor/policy_unpack.c [The conflict is due to the commit ad596ea74e746 ("apparmor: group dfa policydb unpacking") and 98b824ff8984f ("apparmor: refcount the pdb") not being merged. The first commit change profile->policy to *policy and move to a new function: unpack_pdb. And the second commit change *policy to *pdb. So keep use profile-policy in this commit.] Signed-off-by: Zhao Yipeng <zhaoyipeng5@huawei.com> | 2 个月前 | |
bpf: Implement bpf_local_storage for inodes Similar to bpf_local_storage for sockets, add local storage for inodes. The life-cycle of storage is managed with the life-cycle of the inode. i.e. the storage is destroyed along with the owning inode. The BPF LSM allocates an __rcu pointer to the bpf_local_storage in the security blob which are now stackable and can co-exist with other LSMs. Signed-off-by: KP Singh <kpsingh@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20200825182919.1118197-6-kpsingh@chromium.org | 5 年前 | |
ima: Handle error code returned by ima_filter_rule_match() mainline inclusion from mainline-v6.19-rc1 commit 738c9738e690f5cea24a3ad6fd2d9a323cf614f6 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/7810 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=738c9738e690f5cea24a3ad6fd2d9a323cf614f6 -------------------------------- In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match. Fixes: 4af4662fa4a9d ("integrity: IMA policy") Signed-off-by: Zhao Yipeng <zhaoyipeng5@huawei.com> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Zhao Yipeng <zhaoyipeng5@huawei.com> | 6 个月前 | |
security/keys: fix slab-out-of-bounds in key_task_permission maillist inclusion category: Bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAU173 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?id=9bb3ba75c1c8fd8c9f6a0b1fd6409b725583a3e0 ---------------------------------------------------------------------- KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.] Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring") Reported-by: syzbot+5b415c07907a2990d1a3@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000cbb7860611f61147@google.com/T/ Signed-off-by: Chen Ridong <chenridong@huawei.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Yi Yang <yiyang13@huawei.com> | 1 年前 | |
landlock: Don't lose track of restrictions on cred_transfer mainline inclusion from mainline-v6.11-rc1 commit 39705a6c29f8a2b93cf5b99528a55366c50014d1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKPQE CVE: CVE-2024-42318 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=39705a6c29f8a2b93cf5b99528a55366c50014d1 -------------------------------- When a process' cred struct is replaced, this _almost_ always invokes the cred_prepare LSM hook; but in one special case (when KEYCTL_SESSION_TO_PARENT updates the parent's credentials), the cred_transfer LSM hook is used instead. Landlock only implements the cred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causes all information on Landlock restrictions to be lost. This basically means that a process with the ability to use the fork() and keyctl() syscalls can get rid of all Landlock restrictions on itself. Fix it by adding a cred_transfer hook that does the same thing as the existing cred_prepare hook. (Implemented by having hook_cred_prepare() call hook_cred_transfer() so that the two functions are less likely to accidentally diverge in the future.) Cc: stable@kernel.org Fixes: 385975dca53e ("landlock: Set up the security framework and manage credentials") Signed-off-by: Jann Horn <jannh@google.com> Link: https://lore.kernel.org/r/20240724-landlock-houdini-fix-v1-1-df89a4560ca3@google.com Signed-off-by: Mickaël Salaün <mic@digikod.net> Conflicts: security/landlock/cred.c [Just context conflicts.] Signed-off-by: GONG, Ruiqi <gongruiqi1@huawei.com> | 1 年前 | |
LoadPin: Ignore the "contents" argument of the LSM hooks stable inclusion from stable-v5.10.163 commit c3607ed7edfb73f194abfe8d5bbdb8a857266a1f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7PJ9N Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c3607ed7edfb73f194abfe8d5bbdb8a857266a1f ---------------------------------------------------- [ Upstream commit 1a17e5b513ceebf21100027745b8731b4728edf7 ] LoadPin only enforces the read-only origin of kernel file reads. Whether or not it was a partial read isn't important. Remove the overly conservative checks so that things like partial firmware reads will succeed (i.e. reading a firmware header). Fixes: 2039bda1fa8d ("LSM: Add "contents" flag to kernel_read_file hook") Cc: Paul Moore <paul@paul-moore.com> Cc: James Morris <jmorris@namei.org> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: linux-security-module@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Serge Hallyn <serge@hallyn.com> Tested-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://lore.kernel.org/r/20221209195453.never.494-kees@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: zhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com> | 2 年前 | |
Merge branch 'next-general' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Pull lockdown update from James Morris: "An update for the security subsystem to allow unprivileged users to see the status of the lockdown feature. From Jeremy Cline" Also an added comment to describe CAP_SETFCAP. * 'next-general' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: capabilities: add description for CAP_SETFCAP lockdown: Allow unprivileged users to see lockdown status | 5 年前 | |
LSM: SafeSetID: Fix warnings reported by test bot Fix multiple cast-to-union warnings related to casting kuid_t and kgid_t types to kid_t union type. Also fix incompatible type warning that arises from accidental omission of "__rcu" qualifier on the struct setid_ruleset pointer in the argument list for safesetid_file_read(). Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thomas Cedeno <thomascedeno@google.com> Signed-off-by: Micah Morton <mortonm@chromium.org> | 5 年前 | |
selinux: ignore unknown extended permissions stable inclusion from stable-v5.10.233 commit 712137b177b45f255ce5687e679d950fcb218256 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBJ6OD CVE: CVE-2024-57931 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=712137b177b45f255ce5687e679d950fcb218256 -------------------------------- commit 900f83cf376bdaf798b6f5dcb2eae0c822e908b6 upstream. When evaluating extended permissions, ignore unknown permissions instead of calling BUG(). This commit ensures that future permissions can be added without interfering with older kernels. Cc: stable@vger.kernel.org Fixes: fa1aa143ac4a ("selinux: extended permissions for ioctls") Signed-off-by: Thiébaud Weksteen <tweek@google.com> Signed-off-by: Paul Moore <paul@paul-moore.com> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: GONG Ruiqi <gongruiqi1@huawei.com> | 11 个月前 | |
smack: tcp: ipv4, fix incorrect labeling stable inclusion from stable-v5.10.226 commit a948ec993541db4ef392b555c37a1186f4d61670 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAVU3F CVE: CVE-2024-47659 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a948ec993541db4ef392b555c37a1186f4d61670 -------------------------------- [ Upstream commit 2fe209d0ad2e2729f7e22b9b31a86cc3ff0db550 ] Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write. Here is a scenario how to see this: * Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels) * At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment) * At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections * From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works. * Send some data in both directions. * Collect network traffic of this connection. All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C. If anybody cares: exactly the same happens with DCCP. This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided. I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims. Signed-off-by: Konstantin Andreev <andreev@swemel.ru> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2@huawei.com> | 1 年前 | |
exec: Check __FMODE_EXEC instead of in_execve for LSMs mainline inclusion from mainline-v6.8-rc2 commit 4759ff71f23e1a9cba001009abab68cde6dc327a category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IAZ996 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4759ff71f23e1a9cba001009abab68cde6dc327a -------------------------------- After commit 978ffcbf00d8 ("execve: open the executable file before doing anything else"), current->in_execve was no longer in sync with the open(). This broke AppArmor and TOMOYO which depend on this flag to distinguish "open" operations from being "exec" operations. Instead of moving around in_execve, switch to using __FMODE_EXEC, which is where the "is this an exec?" intent is stored. Note that TOMOYO still uses in_execve around cred handling. Reported-by: Kevin Locke <kevin@kevinlocke.name> Closes: https://lore.kernel.org/all/ZbE4qn9_h14OqADK@kevinlocke.name Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Fixes: 978ffcbf00d8 ("execve: open the executable file before doing anything else") Cc: Josh Triplett <josh@joshtriplett.org> Cc: John Johansen <john.johansen@canonical.com> Cc: Paul Moore <paul@paul-moore.com> Cc: James Morris <jmorris@namei.org> Cc: Serge E. Hallyn <serge@hallyn.com> Cc: Kentaro Takeda <takedakn@nttdata.co.jp> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Christian Brauner <brauner@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Eric Biederman <ebiederm@xmission.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: <linux-fsdevel@vger.kernel.org> Cc: <linux-mm@kvack.org> Cc: <apparmor@lists.ubuntu.com> Cc: <linux-security-module@vger.kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Gu Bowen <gubowen5@huawei.com> | 1 年前 | |
task_work: cleanup notification modes A previous commit changed the notification mode from true/false to an int, allowing notify-no, notify-yes, or signal-notify. This was backwards compatible in the sense that any existing true/false user would translate to either 0 (on notification sent) or 1, the latter which mapped to TWA_RESUME. TWA_SIGNAL was assigned a value of 2. Clean this up properly, and define a proper enum for the notification mode. Now we have: - TWA_NONE. This is 0, same as before the original change, meaning no notification requested. - TWA_RESUME. This is 1, same as before the original change, meaning that we use TIF_NOTIFY_RESUME. - TWA_SIGNAL. This uses TIF_SIGPENDING/JOBCTL_TASK_WORK for the notification. Clean up all the callers, switching their 0/1/false/true to using the appropriate TWA_* mode for notifications. Fixes: e91b48162332 ("task_work: teach task_work_add() to do signal_wake_up()") Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jens Axboe <axboe@kernel.dk> | 5 年前 | |
landlock: Set up the security framework and manage credentials mainline inclusion from mainline-v5.13-rc1 commit 385975dca53eb41031d0cbd1de318eb1bc5d6bb9 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6DJU0 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=385975dca53eb41031d0cbd1de318eb1bc5d6bb9 -------------------------------- Process's credentials point to a Landlock domain, which is underneath implemented with a ruleset. In the following commits, this domain is used to check and enforce the ptrace and filesystem security policies. A domain is inherited from a parent to its child the same way a thread inherits a seccomp policy. Cc: James Morris <jmorris@namei.org> Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com> Reviewed-by: Jann Horn <jannh@google.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210422154123.13086-4-mic@digikod.net Signed-off-by: James Morris <jamorris@linux.microsoft.com> Signed-off-by: Yi Yang <yiyang13@huawei.com> | 3 年前 | |
hardening: Remove Clang's enable flag for -ftrivial-auto-var-init=zero stable inclusion from stable-v5.10.150 commit ba52e685d29b942f436ce6d51e787510ed93ef5a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0XA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ba52e685d29b942f436ce6d51e787510ed93ef5a -------------------------------- commit 607e57c6c62c00965ae276902c166834ce73014a upstream. Now that Clang's -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang option is no longer required, remove it from the command line. Clang 16 and later will warn when it is used, which will cause Kconfig to think it can't use -ftrivial-auto-var-init=zero at all. Check for whether it is required and only use it when so. Cc: Nathan Chancellor <nathan@kernel.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: linux-kbuild@vger.kernel.org Cc: llvm@lists.linux.dev Cc: stable@vger.kernel.org Fixes: f02003c860d9 ("hardening: Avoid harmless Clang option under CONFIG_INIT_STACK_ALL_ZERO") Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> | 3 年前 | |
landlock: Add object management mainline inclusion from mainline-v5.13-rc1 commit 90945448e9830aa1b39d7acaa4e0724a001e2ff8 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6DJU0 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90945448e9830aa1b39d7acaa4e0724a001e2ff8 -------------------------------- A Landlock object enables to identify a kernel object (e.g. an inode). A Landlock rule is a set of access rights allowed on an object. Rules are grouped in rulesets that may be tied to a set of processes (i.e. subjects) to enforce a scoped access-control (i.e. a domain). Because Landlock's goal is to empower any process (especially unprivileged ones) to sandbox themselves, we cannot rely on a system-wide object identification such as file extended attributes. Indeed, we need innocuous, composable and modular access-controls. The main challenge with these constraints is to identify kernel objects while this identification is useful (i.e. when a security policy makes use of this object). But this identification data should be freed once no policy is using it. This ephemeral tagging should not and may not be written in the filesystem. We then need to manage the lifetime of a rule according to the lifetime of its objects. To avoid a global lock, this implementation make use of RCU and counters to safely reference objects. A following commit uses this generic object management for inodes. Cc: James Morris <jmorris@namei.org> Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com> Reviewed-by: Jann Horn <jannh@google.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210422154123.13086-2-mic@digikod.net Signed-off-by: James Morris <jamorris@linux.microsoft.com> Signed-off-by: Yi Yang <yiyang13@huawei.com> | 3 年前 | |
capabilities: fix potential memleak on error path from vfs_getxattr_alloc() stable inclusion from stable-v5.10.154 commit cdf01c807e974048c43c7fd3ca574f6086a57906 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cdf01c807e974048c43c7fd3ca574f6086a57906 -------------------------------- commit 8cf0a1bc12870d148ae830a4ba88cfdf0e879cee upstream. In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value, error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |-- *xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it. Cc: stable@vger.kernel.org Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities") Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Acked-by: Serge Hallyn <serge@hallyn.com> [PM: subject line and backtrace tweaks] Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lipeng Sang <sanglipeng1@jd.com> | 3 年前 | |
device_cgroup: Roll back to original exceptions after copy failure stable inclusion from stable-v5.10.163 commit 21a773ec89946522690132b09e5d0bec13bb5d0f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7PJ9N Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=21a773ec89946522690132b09e5d0bec13bb5d0f ---------------------------------------------------- commit e68bfbd3b3c3a0ec3cf8c230996ad8cabe90322f upstream. When add the 'a *:* rwm' entry to devcgroup A's whitelist, at first A's exceptions will be cleaned and A's behavior is changed to DEVCG_DEFAULT_ALLOW. Then parent's exceptions will be copyed to A's whitelist. If copy failure occurs, just return leaving A to grant permissions to all devices. And A may grant more permissions than parent. Backup A's whitelist and recover original exceptions after copy failure. Cc: stable@vger.kernel.org Fixes: 4cef7299b478 ("device_cgroup: add proper checking when changing default behavior") Signed-off-by: Wang Weiyang <wangweiyang2@huawei.com> Reviewed-by: Aristeu Rozanski <aris@redhat.com> Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: zhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com> | 2 年前 | |
Merge branch 'work.mount0' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull vfs mount updates from Al Viro: "The first part of mount updates. Convert filesystems to use the new mount API" * 'work.mount0' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (63 commits) mnt_init(): call shmem_init() unconditionally constify ksys_mount() string arguments don't bother with registering rootfs init_rootfs(): don't bother with init_ramfs_fs() vfs: Convert smackfs to use the new mount API vfs: Convert selinuxfs to use the new mount API vfs: Convert securityfs to use the new mount API vfs: Convert apparmorfs to use the new mount API vfs: Convert openpromfs to use the new mount API vfs: Convert xenfs to use the new mount API vfs: Convert gadgetfs to use the new mount API vfs: Convert oprofilefs to use the new mount API vfs: Convert ibmasmfs to use the new mount API vfs: Convert qib_fs/ipathfs to use the new mount API vfs: Convert efivarfs to use the new mount API vfs: Convert configfs to use the new mount API vfs: Convert binfmt_misc to use the new mount API convenience helper: get_tree_single() convenience helper get_tree_nodev() vfs: Kill sget_userns() ... | 6 年前 | |
dump_common_audit_data(): fix racy accesses to ->d_name stable inclusion from stable-5.10.9 commit a3fddad7af2cd1c60d1ea639a94e7d63c693cd23 bugzilla: 47457 -------------------------------- commit d36a1dd9f77ae1e72da48f4123ed35627848507d upstream. We are not guaranteed the locking environment that would prevent dentry getting renamed right under us. And it's possible for old long name to be freed after rename, leading to UAF here. Cc: stable@kernel.org # v2.6.2+ Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Chen Jun <chenjun102@huawei.com> Acked-by: Xie XiuQi <xiexiuqi@huawei.com> | 5 年前 | |
sysctl: pass kernel pointers to ->proc_handler Instead of having all the sysctl handlers deal with user pointers, which is rather hairy in terms of the BPF interaction, copy the input to and from userspace in common code. This also means that the strings are always NUL-terminated by the common code, making the API a little bit safer. As most handler just pass through the data to one of the common handlers a lot of the changes are mechnical. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Andrey Ignatov <rdna@fb.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> | 6 年前 | |
xen/privcmd: add boot control for restricted usage in domU mainline inclusion from mainline-v7.0-rc6 commit 1613462be621ad5103ec338a7b0ca0746ec4e5f1 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14027 CVE: CVE-2026-31788 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1613462be621ad5103ec338a7b0ca0746ec4e5f1 -------------------------------- When running in an unprivileged domU under Xen, the privcmd driver is restricted to allow only hypercalls against a target domain, for which the current domU is acting as a device model. Add a boot parameter "unrestricted" to allow all hypercalls (the hypervisor will still refuse destructive hypercalls affecting other guests). Make this new parameter effective only in case the domU wasn't started using secure boot, as otherwise hypercalls targeting the domU itself might result in violating the secure boot functionality. This is achieved by adding another lockdown reason, which can be tested to not being set when applying the "unrestricted" option. This is part of XSA-482 Signed-off-by: Juergen Gross <jgross@suse.com> Conflicts: security/security.c include/linux/security.h drivers/xen/privcmd.c [commit b8f3e48834fe8 not merged] Signed-off-by: Zhang Yuwei <zhangyuwei20@huawei.com> | 2 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 个月前 | ||
| 5 年前 | ||
| 6 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 6 年前 | ||
| 2 个月前 |