19 Oct, 2022
1 commit
-
This patch adds trusted hardware key support for DCP crypto driver.
Signed-off-by: Kshitiz Varshney
Reviewed by: Pankaj Gupta
18 Oct, 2022
1 commit
-
Changes done:
- new cmd line option "hw" needs to be suffix, to generate the
hw bound key.
for ex:
$:> keyctl add trusted 'new 32 hw' @s
$:> keyctl add trusted 'load $(cat ) hw' @s
- Key-payload, is added with two more information element specific to HBK
-- flag 'is_hw_bound'
-- structure 'struct hw_bound_key_info hbk_info'Signed-off-by: Pankaj Gupta
Reviewed-by: Gaurav Jain
Reviewed by: Kshitiz Varshney
27 Sep, 2022
1 commit
-
This is the 5.15.70 stable release
* tag 'v5.15.70': (2444 commits)
Linux 5.15.70
ALSA: hda/sigmatel: Fix unused variable warning for beep power change
cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()
...Signed-off-by: Jason Liu
Conflicts:
arch/arm/boot/dts/imx6ul.dtsi
arch/arm/mm/mmu.c
arch/arm64/boot/dts/freescale/imx8mp-evk.dts
drivers/gpu/drm/imx/dcss/dcss-kms.c
drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.h
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
drivers/soc/fsl/Kconfig
drivers/soc/imx/gpcv2.c
drivers/usb/dwc3/host.c
net/dsa/slave.c
sound/soc/fsl/imx-card.c
25 Aug, 2022
8 commits
-
commit 417ea9fe972d2654a268ad66e89c8fcae67017c3 upstream.
When copy_from_user failed, the memory is freed by kvfree. however the
management struct and data blob are allocated independently, so only
kvfree(data) cause a memleak issue here. Use aa_put_loaddata(data) to
fix this issue.Fixes: a6a52579e52b5 ("apparmor: split load data into management struct and data blob")
Signed-off-by: Xiu Jianfeng
Signed-off-by: John Johansen
Signed-off-by: Greg Kroah-Hartman -
commit 11c3627ec6b56c1525013f336f41b79a983b4d46 upstream.
The aa_pivotroot() function has a reference counting bug in a specific
path. When aa_replace_current_label() returns on success, the function
forgets to decrement the reference count of “target”, which is
increased earlier by build_pivotroot(), causing a reference leak.Fix it by decreasing the refcount of “target” in that path.
Fixes: 2ea3ffb7782a ("apparmor: add mount mediation")
Co-developed-by: Xiyu Yang
Signed-off-by: Xiyu Yang
Co-developed-by: Xin Tan
Signed-off-by: Xin Tan
Signed-off-by: Xin Xiong
Signed-off-by: John Johansen
Signed-off-by: Greg Kroah-Hartman -
commit 2504db207146543736e877241f3b3de005cbe056 upstream.
When finding the profile via patterned attachments, the longest left
match is being set to the static compile time value and not using the
runtime computed value.Fix this by setting the candidate value to the greater of the
precomputed value or runtime computed value.Fixes: 21f606610502 ("apparmor: improve overlapping domain attachment resolution")
Signed-off-by: John Johansen
Signed-off-by: Greg Kroah-Hartman -
commit 3bbb7b2e9bbcd22e539e23034da753898fe3b4dc upstream.
When loading a profile that is set to unconfined mode, that label
flag is not set when it should be. Ensure it is set so that when
used in a label the unconfined check will be applied correctly.Fixes: 038165070aa5 ("apparmor: allow setting any profile into the unconfined state")
Signed-off-by: John Johansen
Signed-off-by: Greg Kroah-Hartman -
commit 3e2a3a0830a2090e766d0d887d52c67de2a6f323 upstream.
Clang static analysis reports this issue
label.c:1802:3: warning: 2nd function call argument
is an uninitialized value
pr_info("%s", str);
^~~~~~~~~~~~~~~~~~str is set from a successful call to aa_label_asxprint(&str, ...)
On failure a negative value is returned, not a -1. So change
the check.Fixes: f1bd904175e8 ("apparmor: add the base fns() for domain labels")
Signed-off-by: Tom Rix
Signed-off-by: John Johansen
Signed-off-by: Greg Kroah-Hartman -
commit ec240b5905bbb09a03dccffee03062cf39e38dc2 upstream.
When the mount check fails due to a permission check failure instead
of explicitly at one of the subcomponent checks, AppArmor is reporting
a failure in the flags match. However this is not true and AppArmor
can not attribute the error at this point to any particular component,
and should only indicate the mount failed due to missing permissions.Fixes: 2ea3ffb7782a ("apparmor: add mount mediation")
Signed-off-by: John Johansen
Signed-off-by: Greg Kroah-Hartman -
commit 511f7b5b835726e844a5fc7444c18e4b8672edfd upstream.
AppArmor is prefixing secids that are converted to secctx with the =
to indicate the secctx should only be parsed from an absolute root
POV. This allows catching errors where secctx are reparsed back into
internal labels.Unfortunately because audit is using secid to secctx conversion this
means that subject and object labels can result in a very unfortunate
== that can break audit parsing.eg. the subj==unconfined term in the below audit message
type=USER_LOGIN msg=audit(1639443365.233:160): pid=1633 uid=0 auid=1000
ses=3 subj==unconfined msg='op=login id=1000 exe="/usr/sbin/sshd"
hostname=192.168.122.1 addr=192.168.122.1 terminal=/dev/pts/1 res=success'Fix this by switch the prepending of = to a _. This still works as a
special character to flag this case without breaking audit. Also move
this check behind debug as it should not be needed during normal
operqation.Fixes: 26b7899510ae ("apparmor: add support for absolute root view based labels")
Reported-by: Casey Schaufler
Signed-off-by: John Johansen
Signed-off-by: Greg Kroah-Hartman -
commit 68ff8540cc9e4ab557065b3f635c1ff4c96e1f1c upstream.
Global quieting of denied AppArmor generated file events is not
handled correctly. Unfortunately the is checking if quieting of all
audit events is set instead of just denied events.Fixes: 67012e8209df ("AppArmor: basic auditing infrastructure.")
Signed-off-by: John Johansen
Signed-off-by: Greg Kroah-Hartman
17 Aug, 2022
2 commits
-
[ Upstream commit 15ec76fb29be31df2bccb30fc09875274cba2776 ]
Just like next_entry(), boundary check is necessary to prevent memory
out-of-bound access.Signed-off-by: Xiu Jianfeng
Signed-off-by: Paul Moore
Signed-off-by: Sasha Levin -
[ Upstream commit 73de1befcc53a7c68b0c5e76b9b5ac41c517760f ]
In this function, it directly returns the result of __security_read_policy
without freeing the allocated memory in *data, cause memory leak issue,
so free the memory if __security_read_policy failed.Signed-off-by: Xiu Jianfeng
[PM: subject line tweak]
Signed-off-by: Paul Moore
Signed-off-by: Sasha Levin
29 Jul, 2022
1 commit
-
commit 543ce63b664e2c2f9533d089a4664b559c3e6b5b upstream.
The lockdown LSM is primarily used in conjunction with UEFI Secure Boot.
This LSM may also be used on machines without UEFI. It can also be
enabled when UEFI Secure Boot is disabled. One of lockdown's features
is to prevent kexec from loading untrusted kernels. Lockdown can be
enabled through a bootparam or after the kernel has booted through
securityfs.If IMA appraisal is used with the "ima_appraise=log" boot param,
lockdown can be defeated with kexec on any machine when Secure Boot is
disabled or unavailable. IMA prevents setting "ima_appraise=log" from
the boot param when Secure Boot is enabled, but this does not cover
cases where lockdown is used without Secure Boot.To defeat lockdown, boot without Secure Boot and add ima_appraise=log to
the kernel command line; then:$ echo "integrity" > /sys/kernel/security/lockdown
$ echo "appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig" > \
/sys/kernel/security/ima/policy
$ kexec -ls unsigned-kernelAdd a call to verify ima appraisal is set to "enforce" whenever lockdown
is enabled. This fixes CVE-2022-21505.Cc: stable@vger.kernel.org
Fixes: 29d3c1c8dfe7 ("kexec: Allow kexec_file() with appropriate IMA policy when locked down")
Signed-off-by: Eric Snowberg
Acked-by: Mimi Zohar
Reviewed-by: John Haxby
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
23 Jul, 2022
1 commit
-
commit f43b9876e857c739d407bc56df288b0ebe1a9164 upstream.
Do fine-grained Kconfig for all the various retbleed parts.
NOTE: if your compiler doesn't support return thunks this will
silently 'upgrade' your mitigation to IBPB, you might not like this.Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
[cascardo: there is no CONFIG_OBJTOOL]
[cascardo: objtool calling and option parsing has changed]
Signed-off-by: Thadeu Lima de Souza Cascardo
Signed-off-by: Greg Kroah-Hartman
22 Jul, 2022
4 commits
-
[ Upstream commit 067d2521874135267e681c19d42761c601d503d6 ]
On failure to allocate the SHA1 tfm, IMA fails to initialize and exits
without freeing the ima_algo_array. Add the missing kfree() for
ima_algo_array to avoid the potential memory leak.Signed-off-by: Jianglei Nie
Fixes: 6d94809af6b0 ("ima: Allocate and initialize tfm for each PCR bank")
Signed-off-by: Mimi Zohar
Signed-off-by: Sasha Levin -
[ Upstream commit af16df54b89dee72df253abc5e7b5e8a6d16c11c ]
Currently, an unsigned kernel could be kexec'ed when IMA arch specific
policy is configured unless lockdown is enabled. Enforce kernel
signature verification check in the kexec_file_load syscall when IMA
arch specific policy is configured.Fixes: 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")
Reported-and-suggested-by: Mimi Zohar
Signed-off-by: Coiby Xu
Signed-off-by: Mimi Zohar
Signed-off-by: Sasha Levin -
[ Upstream commit d2ee2cfc4aa85ff6a2a3b198a3a524ec54e3d999 ]
When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be
negative, which may cause the integer overflow problem.Fixes: 39b07096364a ("ima: Implement support for module-style appended signatures")
Signed-off-by: Huaxin Lu
Signed-off-by: Mimi Zohar
Signed-off-by: Sasha Levin -
commit 51dd64bb99e4478fc5280171acd8e1b529eadaf7 upstream.
This reverts commit ccf11dbaa07b328fa469415c362d33459c140a37.
Commit ccf11dbaa07b ("evm: Fix memleak in init_desc") said there is
memleak in init_desc. That may be incorrect, as we can see, tmp_tfm is
saved in one of the two global variables hmac_tfm or evm_tfm[hash_algo],
then if init_desc is called next time, there is no need to alloc tfm
again, so in the error path of kmalloc desc or crypto_shash_init(desc),
It is not a problem without freeing tmp_tfm.And also that commit did not reset the global variable to NULL after
freeing tmp_tfm and this makes *tfm a dangling pointer which may cause a
UAF issue.Reported-by: Guozihua (Scott)
Signed-off-by: Xiu Jianfeng
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
05 Jul, 2022
1 commit
-
This is the 5.15.52 stable release
* tag 'v5.15.52': (28 commits)
Linux 5.15.52
io_uring: fix not locked access to fixed buf table
net: mscc: ocelot: allow unregistered IP multicast flooding to CPU
...Signed-off-by: Jason Liu
02 Jul, 2022
3 commits
-
commit bd303368b776eead1c29e6cdda82bde7128b82a7 upstream.
In previous patches we added new and modified existing helpers to handle
idmapped mounts of filesystems mounted with an idmapping. In this final
patch we convert all relevant places in the vfs to actually pass the
filesystem's idmapping into these helpers.With this the vfs is in shape to handle idmapped mounts of filesystems
mounted with an idmapping. Note that this is just the generic
infrastructure. Actually adding support for idmapped mounts to a
filesystem mountable with an idmapping is follow-up work.In this patch we extend the definition of an idmapped mount from a mount
that that has the initial idmapping attached to it to a mount that has
an idmapping attached to it which is not the same as the idmapping the
filesystem was mounted with.As before we do not allow the initial idmapping to be attached to a
mount. In addition this patch prevents that the idmapping the filesystem
was mounted with can be attached to a mount created based on this
filesystem.This has multiple reasons and advantages. First, attaching the initial
idmapping or the filesystem's idmapping doesn't make much sense as in
both cases the values of the i_{g,u}id and other places where k{g,u}ids
are used do not change. Second, a user that really wants to do this for
whatever reason can just create a separate dedicated identical idmapping
to attach to the mount. Third, we can continue to use the initial
idmapping as an indicator that a mount is not idmapped allowing us to
continue to keep passing the initial idmapping into the mapping helpers
to tell them that something isn't an idmapped mount even if the
filesystem is mounted with an idmapping.Link: https://lore.kernel.org/r/20211123114227.3124056-11-brauner@kernel.org (v1)
Link: https://lore.kernel.org/r/20211130121032.3753852-11-brauner@kernel.org (v2)
Link: https://lore.kernel.org/r/20211203111707.3901969-11-brauner@kernel.org
Cc: Seth Forshee
Cc: Amir Goldstein
Cc: Christoph Hellwig
Cc: Al Viro
CC: linux-fsdevel@vger.kernel.org
Reviewed-by: Seth Forshee
Signed-off-by: Christian Brauner
Signed-off-by: Christian Brauner (Microsoft)
Signed-off-by: Greg Kroah-Hartman -
commit 4472071331549e911a5abad41aea6e3be855a1a4 upstream.
In a few places the vfs needs to interact with bare k{g,u}ids directly
instead of struct inode. These are just a few. In previous patches we
introduced low-level mapping helpers that are able to support
filesystems mounted an idmapping. This patch simply converts the places
to use these new helpers.Link: https://lore.kernel.org/r/20211123114227.3124056-7-brauner@kernel.org (v1)
Link: https://lore.kernel.org/r/20211130121032.3753852-7-brauner@kernel.org (v2)
Link: https://lore.kernel.org/r/20211203111707.3901969-7-brauner@kernel.org
Cc: Seth Forshee
Cc: Amir Goldstein
Cc: Christoph Hellwig
Cc: Al Viro
CC: linux-fsdevel@vger.kernel.org
Reviewed-by: Seth Forshee
Signed-off-by: Christian Brauner
Signed-off-by: Christian Brauner (Microsoft)
Signed-off-by: Greg Kroah-Hartman -
commit a793d79ea3e041081cd7cbd8ee43d0b5e4914a2b upstream.
The low-level mapping helpers were so far crammed into fs.h. They are
out of place there. The fs.h header should just contain the higher-level
mapping helpers that interact directly with vfs objects such as struct
super_block or struct inode and not the bare mapping helpers. Similarly,
only vfs and specific fs code shall interact with low-level mapping
helpers. And so they won't be made accessible automatically through
regular {g,u}id helpers.Link: https://lore.kernel.org/r/20211123114227.3124056-3-brauner@kernel.org (v1)
Link: https://lore.kernel.org/r/20211130121032.3753852-3-brauner@kernel.org (v2)
Link: https://lore.kernel.org/r/20211203111707.3901969-3-brauner@kernel.org
Cc: Seth Forshee
Cc: Christoph Hellwig
Cc: Al Viro
CC: linux-fsdevel@vger.kernel.org
Reviewed-by: Amir Goldstein
Reviewed-by: Seth Forshee
Signed-off-by: Christian Brauner
Signed-off-by: Christian Brauner (Microsoft)
Signed-off-by: Greg Kroah-Hartman
30 Jun, 2022
2 commits
-
This is the 5.15.50 stable release
* tag 'v5.15.50': (1395 commits)
Linux 5.15.50
arm64: mm: Don't invalidate FROM_DEVICE buffers at start of DMA transfer
serial: core: Initialize rs485 RTS polarity already on probe
...Signed-off-by: Jason Liu
Conflicts:
drivers/bus/fsl-mc/fsl-mc-bus.c
drivers/crypto/caam/ctrl.c
drivers/pci/controller/dwc/pci-imx6.c
drivers/spi/spi-fsl-qspi.c
drivers/tty/serial/fsl_lpuart.c
include/uapi/linux/dma-buf.h -
This is the 5.15.41 stable release
* tag 'v5.15.41': (1977 commits)
Linux 5.15.41
usb: gadget: uvc: allow for application to cleanly shutdown
usb: gadget: uvc: rename function to be more consistent
...Signed-off-by: Jason Liu
Conflicts:
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
arch/arm64/configs/defconfig
drivers/clk/imx/clk-imx8qxp-lpcg.c
drivers/dma/imx-sdma.c
drivers/gpu/drm/bridge/nwl-dsi.c
drivers/mailbox/imx-mailbox.c
drivers/net/phy/at803x.c
drivers/tty/serial/fsl_lpuart.c
security/keys/trusted-keys/trusted_core.c
15 Jun, 2022
1 commit
-
commit dda5384313a40ecbaafd8a9a80f47483255e4c4d upstream.
When creating (sealing) a new trusted key, migratable
trusted keys have the FIXED_TPM and FIXED_PARENT attributes
set, and non-migratable keys don't. This is backwards, and
also causes creation to fail when creating a migratable key
under a migratable parent. (The TPM thinks you are trying to
seal a non-migratable blob under a migratable parent.)The following simple patch fixes the logic, and has been
tested for all four combinations of migratable and non-migratable
trusted keys and parent storage keys. With this logic, you will
get a proper failure if you try to create a non-migratable
trusted key under a migratable parent storage key, and all other
combinations work correctly.Cc: stable@vger.kernel.org # v5.13+
Fixes: e5fb5d2c5a03 ("security: keys: trusted: Make sealed key properly interoperable")
Signed-off-by: David Safford
Reviewed-by: Ahmad Fatoum
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman
09 Jun, 2022
11 commits
-
commit 891163adf180bc369b2f11c9dfce6d2758d2a5bd upstream.
The original 'ima' measurement list template contains a hash, defined
as 20 bytes, and a null terminated pathname, limited to 255
characters. Other measurement list templates permit both larger hashes
and longer pathnames. When the "ima" template is configured as the
default, a new measurement list template (ima_template=) must be
specified before specifying a larger hash algorithm (ima_hash=) on the
boot command line.To avoid this boot command line ordering issue, remove the legacy "ima"
template configuration option, allowing it to still be specified on the
boot command line.The root cause of this issue is that during the processing of ima_hash,
we would try to check whether the hash algorithm is compatible with the
template. If the template is not set at the moment we do the check, we
check the algorithm against the configured default template. If the
default template is "ima", then we reject any hash algorithm other than
sha1 and md5.For example, if the compiled default template is "ima", and the default
algorithm is sha1 (which is the current default). In the cmdline, we put
in "ima_hash=sha256 ima_template=ima-ng". The expected behavior would be
that ima starts with ima-ng as the template and sha256 as the hash
algorithm. However, during the processing of "ima_hash=",
"ima_template=" has not been processed yet, and hash_setup would check
the configured hash algorithm against the compiled default: ima, and
reject sha256. So at the end, the hash algorithm that is actually used
will be sha1.With template "ima" removed from the configured default, we ensure that
the default tempalte would at least be "ima-ng" which allows for
basically any hash algorithm.This change would not break the algorithm compatibility checks for IMA.
Fixes: 4286587dccd43 ("ima: add Kconfig default measurement list template")
Signed-off-by: GUO Zihua
Cc:
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman -
commit 8ba0005ff418ec356e176b26eaa04a6ac755d05b upstream.
The original behavior was to check if the full set of requested accesses
was allowed by at least a rule of every relevant layer. This didn't
take into account requests for multiple accesses and same-layer rules
allowing the union of these accesses in a complementary way. As a
result, multiple accesses requested on a file hierarchy matching rules
that, together, allowed these accesses, but without a unique rule
allowing all of them, was illegitimately denied. This case should be
rare in practice and it can only be triggered by the path_rename or
file_open hook implementations.For instance, if, for the same layer, a rule allows execution
beneath /a/b and another rule allows read beneath /a, requesting access
to read and execute at the same time for /a/b should be allowed for this
layer.This was an inconsistency because the union of same-layer rule accesses
was already allowed if requested once at a time anyway.This fix changes the way allowed accesses are gathered over a path walk.
To take into account all these rule accesses, we store in a matrix all
layer granting the set of requested accesses, according to the handled
accesses. To avoid heap allocation, we use an array on the stack which
is 2*13 bytes. A following commit bringing the LANDLOCK_ACCESS_FS_REFER
access right will increase this size to reach 112 bytes (2*14*4) in case
of link or rename actions.Add a new layout1.layer_rule_unions test to check that accesses from
different rules pertaining to the same layer are ORed in a file
hierarchy. Also test that it is not the case for rules from different
layers.Reviewed-by: Paul Moore
Link: https://lore.kernel.org/r/20220506161102.525323-5-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit 2cd7cd6eed88b8383cfddce589afe9c0ae1d19b4 upstream.
This refactoring will be useful in a following commit.
Reviewed-by: Paul Moore
Link: https://lore.kernel.org/r/20220506161102.525323-4-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit 75c542d6c6cc48720376862d5496d51509160dfd upstream.
The maximum number of nested Landlock domains is currently 64. Because
of the following fix and to help reduce the stack size, let's reduce it
to 16. This seems large enough for a lot of use cases (e.g. sandboxed
init service, spawning a sandboxed SSH service, in nested sandboxed
containers). Reducing the number of nested domains may also help to
discover misuse of Landlock (e.g. creating a domain per rule).Add and use a dedicated layer_mask_t typedef to fit with the number of
layers. This might be useful when changing it and to keep it consistent
with the maximum number of layers.Reviewed-by: Paul Moore
Link: https://lore.kernel.org/r/20220506161102.525323-3-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit 5f2ff33e10843ef51275c8611bdb7b49537aba5d upstream.
Create and use the access_mask_t typedef to enforce a consistent access
mask size and uniformly use a 16-bits type. This will helps transition
to a 32-bits value one day.Add a build check to make sure all (filesystem) access rights fit in.
This will be extended with a following commit.Reviewed-by: Paul Moore
Link: https://lore.kernel.org/r/20220506161102.525323-2-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit eba39ca4b155c54adf471a69e91799cc1727873f upstream.
According to the Landlock goal to be a security feature available to
unprivileges processes, it makes more sense to first check for
no_new_privs before checking anything else (i.e. syscall arguments).Merge inval_fd_enforce and unpriv_enforce_without_no_new_privs tests
into the new restrict_self_checks_ordering. This is similar to the
previous commit checking other syscalls.Link: https://lore.kernel.org/r/20220506160820.524344-10-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit 589172e5636c4d16c40b90e87543d43defe2d968 upstream.
This makes more sense to first check the ruleset FD and then the rule
attribute. It will be useful to factor out code for other rule types.Add inval_add_rule_arguments tests, extension of empty_path_beneath_attr
tests, to also check error ordering for landlock_add_rule(2).Link: https://lore.kernel.org/r/20220506160820.524344-9-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit a13e248ff90e81e9322406c0e618cf2168702f4e upstream.
It is not mandatory to pass a file descriptor obtained with the O_PATH
flag. Also, replace rule's accesses with ruleset's accesses.Link: https://lore.kernel.org/r/20220506160820.524344-2-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit 06a1c40a09a8dded4bf0e7e3ccbda6bddcccd7c8 upstream.
Let's follow a consistent and documented coding style. Everything may
not be to our liking but it is better than tacit knowledge. Moreover,
this will help maintain style consistency between different developers.This contains only whitespace changes.
Automatically formatted with:
clang-format-14 -i security/landlock/*.[ch] include/uapi/linux/landlock.hLink: https://lore.kernel.org/r/20220506160513.523257-3-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit 6cc2df8e3a3967e7c13a424f87f6efb1d4a62d80 upstream.
In preparation to a following commit, add clang-format on and
clang-format off stanzas around constant definitions. This enables to
keep aligned values, which is much more readable than packed
definitions.Link: https://lore.kernel.org/r/20220506160513.523257-2-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit 155ca952c7ca19aa32ecfb7373a32bbc2e1ec6eb upstream.
On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables
at early boot to load UEFI Secure Boot certificates, a page fault occurs
in Apple firmware code and EFI runtime services are disabled with the
following logs:[Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000
WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0
(Removed some logs from here)
Call Trace:
page_fault_oops+0x4f/0x2c0
? search_bpf_extables+0x6b/0x80
? search_module_extables+0x50/0x80
? search_exception_tables+0x5b/0x60
kernelmode_fixup_or_oops+0x9e/0x110
__bad_area_nosemaphore+0x155/0x190
bad_area_nosemaphore+0x16/0x20
do_kern_addr_fault+0x8c/0xa0
exc_page_fault+0xd8/0x180
asm_exc_page_fault+0x1e/0x30
(Removed some logs from here)
? __efi_call+0x28/0x30
? switch_mm+0x20/0x30
? efi_call_rts+0x19a/0x8e0
? process_one_work+0x222/0x3f0
? worker_thread+0x4a/0x3d0
? kthread+0x17a/0x1a0
? process_one_work+0x3f0/0x3f0
? set_kthread_struct+0x40/0x40
? ret_from_fork+0x22/0x30
---[ end trace 1f82023595a5927f ]---
efi: Froze efi_rts_wq and disabled EFI Runtime Services
integrity: Couldn't get size: 0x8000000000000015
integrity: MODSIGN: Couldn't get UEFI db list
efi: EFI Runtime Services are disabled!
integrity: Couldn't get size: 0x8000000000000015
integrity: Couldn't get UEFI dbx list
integrity: Couldn't get size: 0x8000000000000015
integrity: Couldn't get mokx list
integrity: Couldn't get size: 0x80000000So we avoid reading these UEFI variables and thus prevent the crash.
Cc: stable@vger.kernel.org
Signed-off-by: Aditya Garg
Reviewed-by: Mimi Zohar
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
25 May, 2022
2 commits
-
commit eadb2f47a3ced5c64b23b90fd2a3463f63726066 upstream.
KGDB and KDB allow read and write access to kernel memory, and thus
should be restricted during lockdown. An attacker with access to a
serial port (for example, via a hypervisor console, which some cloud
vendors provide over the network) could trigger the debugger so it is
important that the debugger respect the lockdown mode when/if it is
triggered.Fix this by integrating lockdown into kdb's existing permissions
mechanism. Unfortunately kgdb does not have any permissions mechanism
(although it certainly could be added later) so, for now, kgdb is simply
and brutally disabled by immediately exiting the gdb stub without taking
any action.For lockdowns established early in the boot (e.g. the normal case) then
this should be fine but on systems where kgdb has set breakpoints before
the lockdown is enacted than "bad things" will happen.CVE: CVE-2022-21499
Co-developed-by: Stephen Brennan
Signed-off-by: Stephen Brennan
Reviewed-by: Douglas Anderson
Signed-off-by: Daniel Thompson
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 6254bd3db316c9ccb3b05caa8b438be63245466f upstream.
The code attempts to free the 'new' pointer using kmem_cache_free(),
which is wrong because this function isn't responsible of freeing it.
Instead, the function should free new->htable and clear the contents of
*new (to prevent double-free).Cc: stable@vger.kernel.org
Fixes: c7c556f1e81b ("selinux: refactor changing booleans")
Reported-by: Wander Lairson Costa
Signed-off-by: Ondrej Mosnacek
Signed-off-by: Paul Moore
Signed-off-by: Greg Kroah-Hartman
04 May, 2022
1 commit
-
The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
built into many newer i.MX and QorIQ SoCs by NXP.The CAAM does crypto acceleration, hardware number generation and
has a blob mechanism for encapsulation/decapsulation of sensitive material.This blob mechanism depends on a device specific random 256-bit One Time
Programmable Master Key that is fused in each SoC at manufacturing
time. This key is unreadable and can only be used by the CAAM for AES
encryption/decryption of user data.This makes it a suitable backend (source) for kernel trusted keys.
Previous commits generalized trusted keys to support multiple backends
and added an API to access the CAAM blob mechanism. Based on these,
provide the necessary glue to use the CAAM for trusted keys.Reviewed-by: David Gstir
Reviewed-by: Pankaj Gupta
Tested-by: Tim Harvey
Tested-by: Matthias Schiffer
Tested-by: Pankaj Gupta
Signed-off-by: Ahmad Fatoum
