| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
apparmor: Fix & Optimize table creation from possibly unaligned memory mainline inclusion from mainline-v7.0-rc1 commit 6fc367bfd4c8886e6b1742aabbd1c0bdc310db3a category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15143 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6fc367bfd4c8886e6b1742aabbd1c0bdc310db3a -------------------------------- Source blob may come from userspace and might be unaligned. Try to optize the copying process by avoiding unaligned memory accesses. - Added Fixes tag - Added "Fix &" to description as this doesn't just optimize but fixes a potential unaligned memory access Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Signed-off-by: Helge Deller <deller@gmx.de> [jj: remove duplicate word "convert" in comment trigger checkpatch warning] Signed-off-by: John Johansen <john.johansen@canonical.com> Conflicts: security/apparmor/include/match.h [Context conflicts.] Signed-off-by: Gu Bowen <gubowen5@huawei.com> | 1 个月前 | |
bpf: lsm: Set bpf_lsm_blob_sizes.lbs_task to 0 stable inclusion from stable-v6.6.54 commit b3c10ac84c5a544ccd92ee4f891441df91a8cfbc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAZ3K2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b3c10ac84c5a544ccd92ee4f891441df91a8cfbc -------------------------------- commit 300a90b2cb5d442879e6398920c49aebbd5c8e40 upstream. bpf task local storage is now using task_struct->bpf_storage, so bpf_lsm_blob_sizes.lbs_task is no longer needed. Remove it to save some memory. Fixes: a10787e6d58c ("bpf: Enable task local storage for tracing programs") Cc: stable@vger.kernel.org Cc: KP Singh <kpsingh@kernel.org> Cc: Matt Bobrowski <mattbobrowski@google.com> Signed-off-by: Song Liu <song@kernel.org> Acked-by: Matt Bobrowski <mattbobrowski@google.com> Link: https://lore.kernel.org/r/20240911055508.9588-1-song@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Wen Zhiwei <wenzhiwei@kylinos.cn> | 1 年前 | |
ima: check return value of crypto_shash_final() in boot aggregate stable inclusion from stable-v6.6.141 commit 5dcb51558e781d6066b3125b07a58c6971581cce category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5dcb51558e781d6066b3125b07a58c6971581cce -------------------------------- commit 5dcb51558e781d6066b3125b07a58c6971581cce upstream. [ Upstream commit 870819434c8dfcc3158033b66e7851b81bb17e21 ] The return value of crypto_shash_final() is not checked in ima_calc_boot_aggregate_tfm(). If the hash finalization fails, the function returns success and a corrupted boot aggregate digest could be used for IMA measurements. Capture the return value and propagate any error to the caller. Fixes: 76bb28f6126f ("ima: use new crypto_shash API instead of old crypto_hash") Signed-off-by: Daniel Hodges <hodgesd@meta.com> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Wang Hai <wanghai38@huawei.com> | 1 个月前 | |
KEYS: trusted_tpm1: Compare HMAC values in constant time stable inclusion from stable-v6.6.113 commit db2fcc8189bfd4dec6cc98e301a23761ccf48572 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8637 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=db2fcc8189bfd4dec6cc98e301a23761ccf48572 -------------------------------- commit eed0e3d305530066b4fc5370107cff8ef1a0d229 upstream. To prevent timing attacks, HMAC value comparison needs to be constant time. Replace the memcmp() with the correct function, crypto_memneq(). [For the Fixes commit I used the commit that introduced the memcmp(). It predates the introduction of crypto_memneq(), but it was still a bug at the time even though a helper function didn't exist yet.] Fixes: d00a1c72f7f4 ("keys: add new trusted key-type") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit db2fcc8189bfd4dec6cc98e301a23761ccf48572) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> | 4 个月前 | |
landlock: Add the errata interface stable inclusion from stable-v6.6.88 commit efde4462b3217e777f385c8d2ade960de3d9666e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ID6MDL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=efde4462b3217e777f385c8d2ade960de3d9666e -------------------------------- commit 15383a0d63dbcd63dc7e8d9ec1bf3a0f7ebf64ac upstream. Some fixes may require user space to check if they are applied on the running kernel before using a specific feature. For instance, this applies when a restriction was previously too restrictive and is now getting relaxed (e.g. for compatibility reasons). However, non-visible changes for legitimate use (e.g. security fixes) do not require an erratum. Because fixes are backported down to a specific Landlock ABI, we need a way to avoid cherry-pick conflicts. The solution is to only update a file related to the lower ABI impacted by this issue. All the ABI files are then used to create a bitmask of fixes. The new errata interface is similar to the one used to get the supported Landlock ABI version, but it returns a bitmask instead because the order of fixes may not match the order of versions, and not all fixes may apply to all versions. The actual errata will come with dedicated commits. The description is not actually used in the code but serves as documentation. Create the landlock_abi_version symbol and use its value to check errata consistency. Update test_base's create_ruleset_checks_ordering tests and add errata tests. This commit is backportable down to the first version of Landlock. Fixes: 3532b0b4352c ("landlock: Enable user space to infer supported features") Cc: Günther Noack <gnoack@google.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250318161443.279194-3-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit efde4462b3217e777f385c8d2ade960de3d9666e) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> | 7 个月前 | |
LoadPin: Annotate struct dm_verity_loadpin_trusted_root_digest with __counted_by Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct dm_verity_loadpin_trusted_root_digest. Additionally, since the element count member must be set before accessing the annotated flexible array member, move its initialization earlier. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Alasdair Kergon <agk@redhat.com> Cc: Mike Snitzer <snitzer@kernel.org> Cc: dm-devel@redhat.com 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 Link: https://lore.kernel.org/r/20230817235955.never.762-kees@kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> | 2 年前 | |
selinux: remove the runtime disable functionality After working with the larger SELinux-based distros for several years, we're finally at a place where we can disable the SELinux runtime disable functionality. The existing kernel deprecation notice explains the functionality and why we want to remove it: The selinuxfs "disable" node allows SELinux to be disabled at runtime prior to a policy being loaded into the kernel. If disabled via this mechanism, SELinux will remain disabled until the system is rebooted. The preferred method of disabling SELinux is via the "selinux=0" boot parameter, but the selinuxfs "disable" node was created to make it easier for systems with primitive bootloaders that did not allow for easy modification of the kernel command line. Unfortunately, allowing for SELinux to be disabled at runtime makes it difficult to secure the kernel's LSM hooks using the "__ro_after_init" feature. It is that last sentence, mentioning the '__ro_after_init' hardening, which is the real motivation for this change, and if you look at the diffstat you'll see that the impact of this patch reaches across all the different LSMs, helping prevent tampering at the LSM hook level. From a SELinux perspective, it is important to note that if you continue to disable SELinux via "/etc/selinux/config" it may appear that SELinux is disabled, but it is simply in an uninitialized state. If you load a policy with load_policy -i, you will see SELinux come alive just as if you had loaded the policy during early-boot. It is also worth noting that the "/sys/fs/selinux/disable" file is always writable now, regardless of the Kconfig settings, but writing to the file has no effect on the system, other than to display an error on the console if a non-zero/true value is written. Finally, in the several years where we have been working on deprecating this functionality, there has only been one instance of someone mentioning any user visible breakage. In this particular case it was an individual's kernel test system, and the workaround documented in the deprecation notice ("selinux=0" on the kernel command line) resolved the issue without problem. Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Paul Moore <paul@paul-moore.com> | 3 年前 | |
safesetid: check size of policy writes stable inclusion from stable-v6.6.78 commit 96fae5bd1589731592d30b3953a90a77ef3928a6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBX1M5 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=96fae5bd1589731592d30b3953a90a77ef3928a6 -------------------------------- [ Upstream commit f09ff307c7299392f1c88f763299e24bc99811c7 ] syzbot attempts to write a buffer with a large size to a sysfs entry with writes handled by handle_policy_update(), triggering a warning in kmalloc. Check the size specified for write buffers before allocating. Reported-by: syzbot+4eb7a741b3216020043a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4eb7a741b3216020043a Signed-off-by: Leo Stone <leocstone@gmail.com> [PM: subject tweak] Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 96fae5bd1589731592d30b3953a90a77ef3928a6) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> | 1 年前 | |
selinux: fix overlayfs mmap() and mprotect() access checks stable inclusion from stable-v6.12.95 commit 8bacd09f12c27710228562e4d13163e58c5f4a45 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15316 CVE: CVE-2026-46054 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8bacd09f12c27710228562e4d13163e58c5f4a45 -------------------------------- [ Upstream commit 82544d36b1729153c8aeb179e84750f0c085d3b1 ] The existing SELinux security model for overlayfs is to allow access if the current task is able to access the top level file (the "user" file) and the mounter's credentials are sufficient to access the lower level file (the "backing" file). Unfortunately, the current code does not properly enforce these access controls for both mmap() and mprotect() operations on overlayfs filesystems. This patch makes use of the newly created security_mmap_backing_file() LSM hook to provide the missing backing file enforcement for mmap() operations, and leverages the backing file API and new LSM blob to provide the necessary information to properly enforce the mprotect() access controls. Cc: stable@vger.kernel.org Acked-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Cai Xinchen <caixinchen1@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Conflicts: security/selinux/hooks.c.rej security/selinux/include/objsec.h.rej [Only context conflicts.] Signed-off-by: Cai Xinchen <caixinchen1@huawei.com> | 8 天前 | |
smack: /smack/doi: accept previously used values stable inclusion from stable-v6.6.128 commit 1c7ee23dfcd18d80770d8f90f2ab5bb1b2bfd8a3 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1c7ee23dfcd18d80770d8f90f2ab5bb1b2bfd8a3 -------------------------------- commit 1c7ee23dfcd18d80770d8f90f2ab5bb1b2bfd8a3 upstream. [ Upstream commit 33d589ed60ae433b483761987b85e0d24e54584e ] Writing to /smack/doi a value that has ever been written there in the past disables networking for non-ambient labels. E.g. # cat /smack/doi 3 # netlabelctl -p cipso list Configured CIPSO mappings (1) DOI value : 3 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (3) domain: "_" (IPv4) protocol: UNLABELED domain: DEFAULT (IPv4) protocol: CIPSO, DOI = 3 domain: DEFAULT (IPv6) protocol: UNLABELED # cat /smack/ambient _ # cat /proc/$$/attr/smack/current _ # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.964 ms # echo foo >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.956 ms unknown option 86 # echo 4 >/smack/doi # echo 3 >/smack/doi !> [ 214.050395] smk_cipso_doi:691 cipso add rc = -17 # echo 3 >/smack/doi !> [ 249.402261] smk_cipso_doi:678 remove rc = -2 !> [ 249.402261] smk_cipso_doi:691 cipso add rc = -17 # ping -c1 10.1.95.12 !!> ping: 10.1.95.12: Address family for hostname not supported # echo _ >/proc/$$/attr/smack/current # ping -c1 10.1.95.12 64 bytes from 10.1.95.12: icmp_seq=1 ttl=64 time=0.617 ms This happens because Smack keeps decommissioned DOIs, fails to re-add them, and consequently refuses to add the “default” domain map: # netlabelctl -p cipso list Configured CIPSO mappings (2) DOI value : 3 mapping type : PASS_THROUGH DOI value : 4 mapping type : PASS_THROUGH # netlabelctl -p map list Configured NetLabel domain mappings (2) domain: "_" (IPv4) protocol: UNLABELED !> (no ipv4 map for default domain here) domain: DEFAULT (IPv6) protocol: UNLABELED Fix by clearing decommissioned DOI definitions and serializing concurrent DOI updates with a new lock. Also: - allow /smack/doi to live unconfigured, since adding a map (netlbl_cfg_cipsov4_map_add) may fail. CIPSO_V4_DOI_UNKNOWN(0) indicates the unconfigured DOI - add new DOI before removing the old default map, so the old map remains if the add fails (2008-02-04, Casey Schaufler) Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") 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: Wang Hai <wanghai38@huawei.com> | 1 个月前 | |
tomoyo: don't emit warning in tomoyo_write_control() stable inclusion from stable-v6.6.78 commit fe1c021eb03dae0dc9dce55e81f77a60e419a27a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBX1M5 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fe1c021eb03dae0dc9dce55e81f77a60e419a27a -------------------------------- [ Upstream commit 3df7546fc03b8f004eee0b9e3256369f7d096685 ] syzbot is reporting too large allocation warning at tomoyo_write_control(), for one can write a very very long line without new line character. To fix this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE, for practically a valid line should be always shorter than 32KB where the "too small to fail" memory-allocation rule applies. One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE. Reported-by: syzbot+7536f77535e5210a5c76@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7536f77535e5210a5c76 Reported-by: Leo Stone <leocstone@gmail.com> Closes: https://lkml.kernel.org/r/20241216021459.178759-2-leocstone@gmail.com Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit fe1c021eb03dae0dc9dce55e81f77a60e419a27a) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> | 1 年前 | |
Merge tag 'sysctl-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux Pull sysctl updates from Luis Chamberlain: "This only does a few sysctl moves from the kernel/sysctl.c file, the rest of the work has been put towards deprecating two API calls which incur recursion and prevent us from simplifying the registration process / saving memory per move. Most of the changes have been soaking on linux-next since v6.3-rc3. I've slowed down the kernel/sysctl.c moves due to Matthew Wilcox's feedback that we should see if we could *save* memory with these moves instead of incurring more memory. We currently incur more memory since when we move a syctl from kernel/sysclt.c out to its own file we end up having to add a new empty sysctl used to register it. To achieve saving memory we want to allow syctls to be passed without requiring the end element being empty, and just have our registration process rely on ARRAY_SIZE(). Without this, supporting both styles of sysctls would make the sysctl registration pretty brittle, hard to read and maintain as can be seen from Meng Tang's efforts to do just this [0]. Fortunately, in order to use ARRAY_SIZE() for all sysctl registrations also implies doing the work to deprecate two API calls which use recursion in order to support sysctl declarations with subdirectories. And so during this development cycle quite a bit of effort went into this deprecation effort. I've annotated the following two APIs are deprecated and in few kernel releases we should be good to remove them: - register_sysctl_table() - register_sysctl_paths() During this merge window we should be able to deprecate and unexport register_sysctl_paths(), we can probably do that towards the end of this merge window. Deprecating register_sysctl_table() will take a bit more time but this pull request goes with a few example of how to do this. As it turns out each of the conversions to move away from either of these two API calls *also* saves memory. And so long term, all these changes *will* prove to have saved a bit of memory on boot. The way I see it then is if remove a user of one deprecated call, it gives us enough savings to move one kernel/sysctl.c out from the generic arrays as we end up with about the same amount of bytes. Since deprecating register_sysctl_table() and register_sysctl_paths() does not require maintainer coordination except the final unexport you'll see quite a bit of these changes from other pull requests, I've just kept the stragglers after rc3" Link: https://lkml.kernel.org/r/ZAD+cpbrqlc5vmry@bombadil.infradead.org [0] * tag 'sysctl-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux: (29 commits) fs: fix sysctls.c built mm: compaction: remove incorrect #ifdef checks mm: compaction: move compaction sysctl to its own file mm: memory-failure: Move memory failure sysctls to its own file arm: simplify two-level sysctl registration for ctl_isa_vars ia64: simplify one-level sysctl registration for kdump_ctl_table utsname: simplify one-level sysctl registration for uts_kern_table ntfs: simplfy one-level sysctl registration for ntfs_sysctls coda: simplify one-level sysctl registration for coda_table fs/cachefiles: simplify one-level sysctl registration for cachefiles_sysctls xfs: simplify two-level sysctl registration for xfs_table nfs: simplify two-level sysctl registration for nfs_cb_sysctls nfs: simplify two-level sysctl registration for nfs4_cb_sysctls lockd: simplify two-level sysctl registration for nlm_sysctls proc_sysctl: enhance documentation xen: simplify sysctl registration for balloon md: simplify sysctl registration hv: simplify sysctl registration scsi: simplify sysctl registration with register_sysctl() csky: simplify alignment sysctl registration ... | 3 年前 | |
proc: add config & param to block forcing mem writes stable inclusion from stable-v6.6.55 commit 8552508033b26803c673598c925257a5ea6f4d98 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IB0MX4 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8552508033b26803c673598c925257a5ea6f4d98 -------------------------------- [ Upstream commit 41e8149c8892ed1962bd15350b3c3e6e90cba7f4 ] This adds a Kconfig option and boot param to allow removing the FOLL_FORCE flag from /proc/pid/mem write calls because it can be abused. The traditional forcing behavior is kept as default because it can break GDB and some other use cases. Previously we tried a more sophisticated approach allowing distributions to fine-tune /proc/pid/mem behavior, however that got NAK-ed by Linus [1], who prefers this simpler approach with semantics also easier to understand for users. Link: https://lore.kernel.org/lkml/CAHk-=wiGWLChxYmUA5HrT5aopZrB7_2VTa0NLZcxORgkUe5tEQ@mail.gmail.com/ [1] Cc: Doug Anderson <dianders@chromium.org> Cc: Jeff Xu <jeffxu@google.com> Cc: Jann Horn <jannh@google.com> Cc: Kees Cook <kees@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Link: https://lore.kernel.org/r/20240802080225.89408-1-adrian.ratiu@collabora.com Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> [ add config to openeuler_defconfig ] (cherry picked from commit 8552508033b26803c673598c925257a5ea6f4d98) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> | 1 年前 | |
hardening: Move BUG_ON_DATA_CORRUPTION to hardening options BUG_ON_DATA_CORRUPTION is turning detected corruptions of list data structures from WARNings into BUGs. This can be useful to stop further corruptions or even exploitation attempts. However, the option has less to do with debugging than with hardening. With the introduction of LIST_HARDENED, it makes more sense to move it to the hardening options, where it selects LIST_HARDENED instead. Without this change, combining BUG_ON_DATA_CORRUPTION with LIST_HARDENED alone wouldn't be possible, because DEBUG_LIST would always be selected by BUG_ON_DATA_CORRUPTION. Signed-off-by: Marco Elver <elver@google.com> Link: https://lore.kernel.org/r/20230811151847.1594958-4-elver@google.com Signed-off-by: Kees Cook <keescook@chromium.org> | 2 年前 | |
security: remove unneeded subdir-$(CONFIG_...) All of these are unneeded. The directories to descend are specified by obj-$(CONFIG_...). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> | 4 年前 | |
lsm: constify the 'target' parameter in security_capget() Three LSMs register the implementations for the "capget" hook: AppArmor, SELinux, and the normal capability code. Looking at the function implementations we may observe that the first parameter "target" is not changing. Mark the first argument "target" of LSM hook security_capget() as "const" since it will not be changing in the LSM hook. cap_capget() LSM hook declaration exceeds the 80 characters per line limit. Split the function declaration to multiple lines to decrease the line length. Signed-off-by: Khadija Kamran <kamrankhadijadj@gmail.com> Acked-by: John Johansen <john.johansen@canonical.com> [PM: align the cap_capget() declaration, spelling fixes] Signed-off-by: Paul Moore <paul@paul-moore.com> | 2 年前 | |
cgroup/dmem: reuse SUBSYS for dmem and devices to preserve KABI hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8424 ---------------------------------------- Adding and enabling a new subsystem would increment CGROUP_SUBSYS_COUNT, which leads to Kernel ABI (KABI) breakage. This patch introduces a mechanism to share the same SUBSYS(dmem) slot between the 'dmem' and 'devices' subsystems. Since 'dmem' is a cgroup v2-only controller and 'devices' is a cgroup v1-only controller, they are mutually exclusive at runtime. We introduce a new kernel command line parameter, "dmem", to control this behavior dynamically. This approach allows us to enable both CONFIG_CGROUP_DMEM and CONFIG_CGROUP_DEVICE simultaneously without exceeding the subsystem limit. The behavior based on the "dmem" cmdline parameter is as follows: 1. dmem=disable, cgroup v1: - The legacy 'devices' subsystem is active and functional. - The 'dmem' subsystem remains dormant. 2. dmem=enable, cgroup v1: - The 'devices' subsystem is effectively disabled/blocked. 3. dmem=disable, cgroup v2: - The 'dmem' subsystem is blocked in the hierarchy. 4. dmem=enable, cgroup v2: - The 'dmem' subsystem is active and usable. - The 'devices' logic is bypassed. This ensures backward compatibility for v1 users while enabling the new functionality for v2, all within the constraints of the kernel subsystem limit. Fixes: b168ed458dde ("kernel/cgroup: Add "dmem" memory accounting cgroup") Signed-off-by: Liu Kai <liukai284@huawei.com> | 3 个月前 | |
securityfs: don't pin dentries twice, once is enough... stable inclusion from stable-v6.6.103 commit d7e28036b0e938c689d98efa812d4138cda38e07 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8365 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d7e28036b0e938c689d98efa812d4138cda38e07 -------------------------------- [ Upstream commit 27cd1bf1240d482e4f02ca4f9812e748f3106e4f ] incidentally, securityfs_recursive_remove() is broken without that - it leaks dentries, since simple_recursive_removal() does not expect anything of that sort. It could be worked around by dput() in remove_one() callback, but it's easier to just drop that double-get stuff. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit d7e28036b0e938c689d98efa812d4138cda38e07) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> | 5 个月前 | |
lsm: fix a number of misspellings A random collection of spelling fixes for source files in the LSM layer. Reviewed-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Paul Moore <paul@paul-moore.com> | 3 年前 | |
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 年前 | |
lsm: add backing_file LSM hooks stable inclusion from stable-v6.12.95 commit 5b6aa9a843205da92d860e5011a7b29062a76b8f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15316 CVE: CVE-2026-46054 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5b6aa9a843205da92d860e5011a7b29062a76b8f -------------------------------- [ Upstream commit 6af36aeb147a06dea47c49859cd6ca5659aeb987 ] Stacked filesystems such as overlayfs do not currently provide the necessary mechanisms for LSMs to properly enforce access controls on the mmap() and mprotect() operations. In order to resolve this gap, a LSM security blob is being added to the backing_file struct and the following new LSM hooks are being created: security_backing_file_alloc() security_backing_file_free() security_mmap_backing_file() The first two hooks are to manage the lifecycle of the LSM security blob in the backing_file struct, while the third provides a new mmap() access control point for the underlying backing file. It is also expected that LSMs will likely want to update their security_file_mprotect() callback to address issues with their mprotect() controls, but that does not require a change to the security_file_mprotect() LSM hook. There are a three other small changes to support these new LSM hooks: * Pass the user file associated with a backing file down to alloc_empty_backing_file() so it can be included in the security_backing_file_alloc() hook. * Add getter and setter functions for the backing_file struct LSM blob as the backing_file struct remains private to fs/file_table.c. * Constify the file struct field in the LSM common_audit_data struct to better support LSMs that need to pass a const file struct pointer into the common LSM audit code. Thanks to Arnd Bergmann for identifying the missing EXPORT_SYMBOL_GPL() and supplying a fixup. Cc: stable@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: linux-unionfs@vger.kernel.org Cc: linux-erofs@lists.ozlabs.org Reviewed-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Paul Moore <paul@paul-moore.com> [ Mainline declares lsm_backing_file_cache in security/lsm.h. Linux 6.12.y does not have security/lsm_init.c or security/lsm.h; the cache variable is defined locally as static struct kmem_cache *lsm_backing_file_cache in security/security.c. ] Signed-off-by: Cai Xinchen <caixinchen1@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Conflicts: fs/backing-file.c fs/file_table.c fs/overlayfs/dir.c fs/overlayfs/file.c include/linux/backing-file.h include/linux/fs.h include/linux/lsm_hook_defs.h include/linux/lsm_hooks.h include/linux/security.h security/security.c [The function backing_tmpfile_open and ovl_create_tmpfile is not backport to OLK-6.6. 6.12.y uses call_int_hook(FUNC, ...) with the default IRC baked into the macro. OLK-6.6 uses call_int_hook(FUNC, IRC, ...) requiring an explicit default return value. Others are context conflicts.] Signed-off-by: Cai Xinchen <caixinchen1@huawei.com> | 8 天前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 个月前 | ||
| 1 年前 | ||
| 1 个月前 | ||
| 4 个月前 | ||
| 7 个月前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 8 天前 | ||
| 1 个月前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 3 个月前 | ||
| 5 个月前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 8 天前 |