Pull misc fixes from Andrew Morton:
"25 hotfixes. 16 are cc:stable. 19 are MM and 6 are non-MM.
The usual bunch of singletons and doubletons - please see the relevant
changelogs for details"
* tag 'mm-hotfixes-stable-2024-12-21-12-09' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (25 commits)
mm: huge_memory: handle strsep not finding delimiter
alloc_tag: fix set_codetag_empty() when !CONFIG_MEM_ALLOC_PROFILING_DEBUG
alloc_tag: fix module allocation tags populated area calculation
mm/codetag: clear tags before swap
mm/vmstat: fix a W=1 clang compiler warning
mm: convert partially_mapped set/clear operations to be atomic
nilfs2: fix buffer head leaks in calls to truncate_inode_pages()
vmalloc: fix accounting with i915
mm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_buddy()
fork: avoid inappropriate uprobe access to invalid mm
nilfs2: prevent use of deleted inode
zram: fix uninitialized ZRAM not releasing backing device
zram: refuse to use zero sized block device as backing device
mm: use clear_user_(high)page() for arch with special user folio handling
mm: introduce cpu_icache_is_aliasing() across all architectures
mm: add RCU annotation to pte_offset_map(_lock)
mm: correctly reference merged VMA
mm: use aligned address in copy_user_gigantic_page()
mm: use aligned address in clear_gigantic_page()
mm: shmem: fix ShmemHugePages at swapout
...
Renesas DTS updates for v6.14
- Add more serial (SCIF), power monitor, ADC, and sound support for
the RZ/G3S SoC and the RZ/G3S SMARC SoM and development board,
- Add support for the R-Car V4H ES3.0 (R8A779G3) SoC on the White Hawk
Single development board,
- Add display support for the R-Car V4M SoC and the Gray Hawk Single
development board,
- Add video capture support for the Gray Hawk Single development
board,
- Add initial support for the RZ/G3E (R9A09G047) SoC and the RZ/G3E
SMARC SoM and Carrier-II EVK development board,
- Add support for 5-port MATEnet on the Falcon Ethernet sub-board,
- Miscellaneous fixes and improvements.
* tag 'renesas-dts-for-v6.14-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: (33 commits)
arm64: dts: renesas: r9a09g047: Add I2C nodes
arm64: dts: renesas: rzg3s-smarc: Add sound card
arm64: dts: renesas: rzg3s-smarc: Enable SSI3
arm64: dts: renesas: Add da7212 audio codec node
arm64: dts: renesas: rzg3s-smarc-som: Add versa3 clock generator node
arm64: dts: renesas: r9a08g045: Add SSI nodes
arm64: dts: renesas: rzg3s-smarc-som: Enable ADC
arm64: dts: renesas: r9a08g045: Add ADC node
arm64: dts: renesas: Add initial device tree for RZ/G3E SMARC EVK board
arm64: dts: renesas: Add initial support for RZ/G3E SMARC SoM
arm64: dts: renesas: r9a09g047: Add OPP table
arm64: dts: renesas: Add initial DTSI for RZ/G3E SoC
arm64: dts: renesas: falcon-ethernet: Describe PHYs connected on the breakout board
arm64: dts: renesas: r8a779a0: Remove address- and size-cells from AVB[1-5]
dt-bindings: clock: renesas: Document RZ/G3E SoC CPG
dt-bindings: soc: renesas: Document RZ/G3E SMARC SoM and Carrier-II EVK
dt-bindings: soc: renesas: Document Renesas RZ/G3E SoC variants
arm64: dts: renesas: gray-hawk-single: Add video capture support
arm64: dts: renesas: gray-hawk-single: Add DisplayPort support
arm64: dts: renesas: r8a779h0: Add display support
...
Link: https://lore.kernel.org/r/cover.1734689803.git.geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
STM32 DT for v6.14, round 1
Highlights:
----------
- MPU:
- STM32MP13:
- Populate all timer counter nodes in Soc file.
- Enable counter (timers) on stm32mp135f-dk.
- DH core: increase CPU voltage to fit with STM32MP135F datasheet.
- STMP32MP15:
- Populate all timer counter nodes in Soc file.
- Enable counter (timers) on stm32mp15 EV1 and DK boards.
- OCTAVO:
- LXA-TAC (gen1/2): disable RTC, update aliases and
adjust USB gadget.
- Add LXA-TAC gen3 based on OSD32MP153x SIP:
STMP32MP153, RAM, PMIC.
- DH: minor fixes.
- STM32MP25:
- Enable imx335/CSI/DCMIPP pipeline on stm32mp257f-ev1.
- Add I2S, SAI, SPDIFRX supports.
- Add and enable COMBOPHY on stm32mp257f-ev1. Combophy is used
by PCIe and USB3.
* tag 'stm32-dt-for-v6.14-1' of https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: (23 commits)
arm64: dts: st: enable imx335/csi/dcmipp pipeline on stm32mp257f-ev1
arm64: dts: st: add csi & dcmipp node in stm32mp25
ARM: dts: stm32: Swap USART3 and UART8 alias on STM32MP15xx DHCOM SoM
ARM: dts: stm32: add counter subnodes on stm32mp157 dk boards
ARM: dts: stm32: add counter subnodes on stm32mp157c-ev1
ARM: dts: stm32: add counter subnodes on stm32mp135f-dk
ARM: dts: stm32: populate all timer counter nodes on stm32mp15
ARM: dts: stm32: populate all timer counter nodes on stm32mp13
ARM: dts: stm32: lxa-tac: Add support for generation 3 devices
ARM: dts: stm32: lxa-tac: move adc and gpio{e,g} to gen{1,2} boards
dt-bindings: arm: stm32: add compatible strings for Linux Automation LXA TAC gen 3
ARM: dts: stm32: lxa-tac: adjust USB gadget fifo sizes for multi function
ARM: dts: stm32: lxa-tac: extend the alias table
ARM: dts: stm32: lxa-tac: disable the real time clock
ARM: dts: stm32: Fix IPCC EXTI declaration on stm32mp151
ARM: dts: stm32: Sort M24256E write-lockable page in DH STM32MP13xx DHCOR SoM DT
ARM: dts: stm32: Increase CPU core voltage on STM32MP13xx DHCOR SoM
ARM: dts: stm32: Deduplicate serial aliases and chosen node for STM32MP15xx DHCOM SoM
arm64: dts: st: Enable COMBOPHY on the stm32mp257f-ev1 board
arm64: dts: st: Add combophy node on stm32mp251
...
Link: https://lore.kernel.org/r/7ffcca65-3953-413a-bcf3-0702a6b0518b@foss.st.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
With DT properties charge-current-limit-gpios and
charge-current-limit-mapping one can define charge current limits in uA
using up to 32 GPIOs. Add property charge-current-limit-default-microamp
which selects a default charge current limit that must be listed in
charge-current-limit-mapping.
This is helpful when the smallest possible charge current limit is 0uA. The
driver defaults to the smallest possible value at the moment, which
disables charging on probe. With the default its possible to setup a safe
charge current limit.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
Link: https://lore.kernel.org/r/20241218-default-charge-current-limit-v3-1-b26118cf06b5@liebherr.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Define how to handle buffers with multiple possible placement so we
don't get incompatible implementations. Callout the resident requirement
for drm-purgeable- explicitly. Remove the requirement for there to be
only drm-memory- or only drm-resident-, it's not what's implemented and
having both is better for back-compat. Also re-order the paragraphs to
flow better.
Signed-off-by: Yunxiang Li <Yunxiang.Li@amd.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219151411.1150-4-Yunxiang.Li@amd.com
Signed-off-by: Christian König <christian.koenig@amd.com>
Each data lane on a CSI-2 C-PHY bus uses three phase encoding and is
constructed from three physical wires. The wires are referred to as A, B
and C and their default order is ABC. However to ease hardware design
the specification allows for the wires to be switched in any order.
Add a vendor neutral property to describe the line order used. The
property name 'line-orders', the possible values it can be assigned and
there names are taken from the MIPI Discovery and Configuration (DisCo)
Specification for Imaging.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The DP subsystem for ZynqMP supports audio via two channels, and the DP
DMA has dma-engines for those channels. For some reason the DT binding
has not specified those channels, even if the picture included in
xlnx,zynqmp-dpsub.yaml shows "2 x aud" DMAs.
This hasn't caused any issues as the drivers have not supported audio,
and has thus gone unnoticed.
To make it possible to add the audio support to the driver, add the two
audio DMAs to the binding. While strictly speaking this is an ABI break,
there should be no regressions caused by this as we're adding new
entries at the end of the dmas list, and, after the audio support has
been added in "arm64: dts: zynqmp: Add DMA for DP audio", the driver
will treat the audio DMAs as optional to also support the old bindings.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241023-xilinx-dp-audio-v4-1-5128881457be@ideasonboard.com
The new SECBIT_EXEC_RESTRICT_FILE, SECBIT_EXEC_DENY_INTERACTIVE, and
their *_LOCKED counterparts are designed to be set by processes setting
up an execution environment, such as a user session, a container, or a
security sandbox. Unlike other securebits, these ones can be set by
unprivileged processes. Like seccomp filters or Landlock domains, the
securebits are inherited across processes.
When SECBIT_EXEC_RESTRICT_FILE is set, programs interpreting code should
control executable resources according to execveat(2) + AT_EXECVE_CHECK
(see previous commit).
When SECBIT_EXEC_DENY_INTERACTIVE is set, a process should deny
execution of user interactive commands (which excludes executable
regular files).
Being able to configure each of these securebits enables system
administrators or owner of image containers to gradually validate the
related changes and to identify potential issues (e.g. with interpreter
or audit logs).
It should be noted that unlike other security bits, the
SECBIT_EXEC_RESTRICT_FILE and SECBIT_EXEC_DENY_INTERACTIVE bits are
dedicated to user space willing to restrict itself. Because of that,
they only make sense in the context of a trusted environment (e.g.
sandbox, container, user session, full system) where the process
changing its behavior (according to these bits) and all its parent
processes are trusted. Otherwise, any parent process could just execute
its own malicious code (interpreting a script or not), or even enforce a
seccomp filter to mask these bits.
Such a secure environment can be achieved with an appropriate access
control (e.g. mount's noexec option, file access rights, LSM policy) and
an enlighten ld.so checking that libraries are allowed for execution
e.g., to protect against illegitimate use of LD_PRELOAD.
Ptrace restrictions according to these securebits would not make sense
because of the processes' trust assumption.
Scripts may need some changes to deal with untrusted data (e.g. stdin,
environment variables), but that is outside the scope of the kernel.
See chromeOS's documentation about script execution control and the
related threat model:
https://www.chromium.org/chromium-os/developer-library/guides/security/noexec-shell-scripts/
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Paul Moore <paul@paul-moore.com>
Reviewed-by: Serge Hallyn <serge@hallyn.com>
Reviewed-by: Jeff Xu <jeffxu@chromium.org>
Tested-by: Jeff Xu <jeffxu@chromium.org>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20241212174223.389435-3-mic@digikod.net
Signed-off-by: Kees Cook <kees@kernel.org>
Add a new AT_EXECVE_CHECK flag to execveat(2) to check if a file would
be allowed for execution. The main use case is for script interpreters
and dynamic linkers to check execution permission according to the
kernel's security policy. Another use case is to add context to access
logs e.g., which script (instead of interpreter) accessed a file. As
any executable code, scripts could also use this check [1].
This is different from faccessat(2) + X_OK which only checks a subset of
access rights (i.e. inode permission and mount options for regular
files), but not the full context (e.g. all LSM access checks). The main
use case for access(2) is for SUID processes to (partially) check access
on behalf of their caller. The main use case for execveat(2) +
AT_EXECVE_CHECK is to check if a script execution would be allowed,
according to all the different restrictions in place. Because the use
of AT_EXECVE_CHECK follows the exact kernel semantic as for a real
execution, user space gets the same error codes.
An interesting point of using execveat(2) instead of openat2(2) is that
it decouples the check from the enforcement. Indeed, the security check
can be logged (e.g. with audit) without blocking an execution
environment not yet ready to enforce a strict security policy.
LSMs can control or log execution requests with
security_bprm_creds_for_exec(). However, to enforce a consistent and
complete access control (e.g. on binary's dependencies) LSMs should
restrict file executability, or measure executed files, with
security_file_open() by checking file->f_flags & __FMODE_EXEC.
Because AT_EXECVE_CHECK is dedicated to user space interpreters, it
doesn't make sense for the kernel to parse the checked files, look for
interpreters known to the kernel (e.g. ELF, shebang), and return ENOEXEC
if the format is unknown. Because of that, security_bprm_check() is
never called when AT_EXECVE_CHECK is used.
It should be noted that script interpreters cannot directly use
execveat(2) (without this new AT_EXECVE_CHECK flag) because this could
lead to unexpected behaviors e.g., `python script.sh` could lead to Bash
being executed to interpret the script. Unlike the kernel, script
interpreters may just interpret the shebang as a simple comment, which
should not change for backward compatibility reasons.
Because scripts or libraries files might not currently have the
executable permission set, or because we might want specific users to be
allowed to run arbitrary scripts, the following patch provides a dynamic
configuration mechanism with the SECBIT_EXEC_RESTRICT_FILE and
SECBIT_EXEC_DENY_INTERACTIVE securebits.
This is a redesign of the CLIP OS 4's O_MAYEXEC:
f5cb330d6b/1901_open_mayexec.patch
This patch has been used for more than a decade with customized script
interpreters. Some examples can be found here:
https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Acked-by: Paul Moore <paul@paul-moore.com>
Reviewed-by: Serge Hallyn <serge@hallyn.com>
Reviewed-by: Jeff Xu <jeffxu@chromium.org>
Tested-by: Jeff Xu <jeffxu@chromium.org>
Link: https://docs.python.org/3/library/io.html#io.open_code [1]
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20241212174223.389435-2-mic@digikod.net
Signed-off-by: Kees Cook <kees@kernel.org>
Unconditionally advertise TSC_DEADLINE_TIMER via KVM_GET_SUPPORTED_CPUID,
as KVM always emulates deadline mode, *if* the VM has an in-kernel local
APIC. The odds of a VMM emulating the local APIC in userspace, not
emulating the TSC deadline timer, _and_ reflecting
KVM_GET_SUPPORTED_CPUID back into KVM_SET_CPUID2, i.e. the risk of
over-advertising and breaking any setups, is extremely low.
KVM has _unconditionally_ advertised X2APIC via CPUID since commit
0d1de2d901 ("KVM: Always report x2apic as supported feature"), and it
is completely impossible for userspace to emulate X2APIC as KVM doesn't
support forwarding the MSR accesses to userspace. I.e. KVM has relied on
userspace VMMs to not misreport local APIC capabilities for nearly 13
years.
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20241128013424.4096668-38-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Merge amd-pstate driver fixes for 6.13-rc4 from Mario Liminciello:
"Fix a problem where systems without preferred cores were
misdetecting preferred cores.
Fix issues with with boost numerator handling leading to
inconsistently programmed CPPC max performance values."
* tag 'amd-pstate-v6.13-2024-12-11' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux:
cpufreq/amd-pstate: Use boost numerator for upper bound of frequencies
cpufreq/amd-pstate: Store the boost numerator as highest perf again
cpufreq/amd-pstate: Detect preferred core support before driver registration
