Pull arm64 fixes from Will Deacon:
"The bulk of the diffstat consists of changes to our uaccess routines
so that they fall back to bytewise copying prior to reporting complete
failure when the initial (multi-byte) access faults.
However, the most disappointing change here is that we've had to bump
ARCH_DMA_MINALIGN back to 128 bytes thanks to Qualcomm's "Kryo" CPU,
which ended up in the MSM8996 mobile SoC. Still, at least we're now
aware of this design and one of the hardware designers confirmed the
L2 cacheline size for us.
Summary:
- Fix instrumentation annotations for entry code
- Ensure kernel MTE state is restored correctly on resume from suspend
- Fix MTE fault from new strlen() routine
- Fallback to byte-wise accesses on initial uaccess fault
- Bump Clang requirement for BTI
- Revert ARCH_DMA_MINALIGN back to 128 bytes (shakes fist at Qualcomm)"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: entry: fix KCOV suppression
arm64: entry: add missing noinstr
arm64: mte: fix restoration of GCR_EL1 from suspend
arm64: Avoid premature usercopy failure
arm64: Restrict ARM64_BTI_KERNEL to clang 12.0.0 and newer
Revert "arm64: cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)"
arm64: Add missing header <asm/smp.h> in two files
arm64: fix strlen() with CONFIG_KASAN_HW_TAGS
In nf_tables_commit, if nf_tables_commit_audit_alloc fails, it does not
free the adp variable.
Fix this by adding nf_tables_commit_audit_free which frees
the linked list with the head node adl.
backtrace:
kmalloc include/linux/slab.h:591 [inline]
kzalloc include/linux/slab.h:721 [inline]
nf_tables_commit_audit_alloc net/netfilter/nf_tables_api.c:8439 [inline]
nf_tables_commit+0x16e/0x1760 net/netfilter/nf_tables_api.c:8508
nfnetlink_rcv_batch+0x512/0xa80 net/netfilter/nfnetlink.c:562
nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline]
nfnetlink_rcv+0x1fa/0x220 net/netfilter/nfnetlink.c:652
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x2c7/0x3e0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x36b/0x6b0 net/netlink/af_netlink.c:1929
sock_sendmsg_nosec net/socket.c:702 [inline]
sock_sendmsg+0x56/0x80 net/socket.c:722
Reported-by: syzbot <syzkaller@googlegroups.com>
Reported-by: kernel test robot <lkp@intel.com>
Fixes: c520292f29 ("audit: log nftables configuration change events once per table")
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
The commit 9a5605505d (" bonding: Add struct bond_ipesc to manage SA") is causing
following build error when XFRM is not selected in kernel config.
lld: error: undefined symbol: xfrm_dev_state_flush
>>> referenced by bond_main.c:3453 (drivers/net/bonding/bond_main.c:3453)
>>> net/bonding/bond_main.o:(bond_netdev_event) in archive drivers/built-in.a
Fixes: 9a5605505d (" bonding: Add struct bond_ipesc to manage SA")
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
CC: Taehee Yoo <ap420073@gmail.com>
CC: Jay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As of commit c7289b1c8a ("arm64: tegra: Enable SMMU support on
Tegra194"), SMMU support is enabled system-wide on Tegra194. However,
there was a bit of overlap between the SMMU enablement and the PCIe
support addition, so the PCIe device tree nodes are missing the iommus
and interconnects properties. This in turn leads to SMMU faults for
these devices, since by default the ARM SMMU will fault.
Add the iommus and interconnects properties to all the PCIe device
tree nodes to restore their functionality.
Fixes: c7289b1c8a ("arm64: tegra: Enable SMMU support on Tegra194")
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The release_sock() is blocking function, it would change the state
after sleeping. use wait_woken() instead.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Yajun Deng <yajun.deng@linux.dev>
Signed-off-by: David S. Miller <davem@davemloft.net>
Once the new schema interrupt-controller/arm,vic.yaml is added, we get
the below warnings:
arch/arm/boot/dts/versatile-ab.dt.yaml:
intc@10140000: $nodename:0: 'intc@10140000' does not match
'^interrupt-controller(@[0-9a-f,]+)*$'
arch/arm/boot/dts/versatile-ab.dt.yaml:
intc@10140000: 'clear-mask' does not match any of the regexes
Fix the node names for the interrupt controller to conform
to the standard node name interrupt-controller@.. Also drop invalid
clear-mask property.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210701132118.759454-1-sudeep.holla@arm.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The usage of usb-nop-xceiv PHY on Raspberry Pi boards with BCM283x has
been a "regression source" a lot of times. The last case is breakage of
USB mass storage boot has been commit e590474768 ("driver core: Set
fw_devlink=on by default") for multi_v7_defconfig. As long as
NOP_USB_XCEIV is configured as module, the dwc2 USB driver defer probing
endlessly and prevent booting from USB mass storage device. So make
the driver built-in as in bcm2835_defconfig and arm64/defconfig.
Fixes: e590474768 ("driver core: Set fw_devlink=on by default")
Reported-by: Ojaswin Mujoo <ojaswin98@gmail.com>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Link: https://lore.kernel.org/r/1625915095-23077-1-git-send-email-stefan.wahren@i2se.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This updates the Versatile Express defconfig for the changes
in the v5.14-rc1 kernel:
- The Framebuffer CONFIG_FB needs to be explicitly selected
or we don't get any framebuffer anymore. DRM has stopped to
select FB because of circular dependency.
- CONFIG_CMA options were moved around.
- CONFIG_MODULES options were moved around.
- CONFIG_CRYPTO_HW was moved around.
Fixes: f611b1e762 ("drm: Avoid circular dependencies for CONFIG_FB")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/20210713133708.94397-1-linus.walleij@linaro.org'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This updates the Versatile defconfig for the changes
in the v5.14-rc1 kernel:
- The Framebuffer CONFIG_FB needs to be explicitly selected
or we don't get any framebuffer anymore. DRM has stopped to
select FB because of circular dependency.
- The CONFIG_FB_MODE_HELPERS are not needed when using DRM
framebuffer emulation as DRM does.
- The Acorn fonts are removed, the default framebuffer font
works fine. I don't know why this was selected in the first
place or how the Kconfig was altered so it was removed.
Fixes: f611b1e762 ("drm: Avoid circular dependencies for CONFIG_FB")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210714081819.139210-1-linus.walleij@linaro.org'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This updates the RealView defconfig for the changes
in the v5.14-rc1 kernel:
- The Framebuffer CONFIG_FB needs to be explicitly selected
or we don't get any framebuffer anymore. DRM has stopped to
select FB because of circular dependency.
- The CONFIG_FB_MODE_HELPERS are not needed when using DRM
framebuffer emulation as DRM does.
- Drop two unused penguin logos.
Fixes: f611b1e762 ("drm: Avoid circular dependencies for CONFIG_FB")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210714090040.182381-1-linus.walleij@linaro.org'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This updates the Integrator defconfig for the changes
in the v5.14-rc1 kernel:
- The Framebuffer CONFIG_FB needs to be explicitly selected
or we don't get any framebuffer anymore. DRM has stopped to
select FB because of circular dependency.
- Drop the unused Matrox FB drivers that are only used with
specific PCI cards.
Fixes: f611b1e762 ("drm: Avoid circular dependencies for CONFIG_FB")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210714122703.212609-1-linus.walleij@linaro.org'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
ARM SCMI fixes for v5.14
A small set of fixes:
- adding check for presence of probe while registering the driver to
prevent NULL pointer access
- dropping the duplicate check as the driver core already takes care of it
- fix for possible scmi_linux_errmap buffer overflow
- fix to avoid sensor message structure padding
- fix the range check for the maximum number of pending SCMI messages
- fix for various kernel-doc warnings
* tag 'scmi-fixes-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Fix range check for the maximum number of pending messages
firmware: arm_scmi: Avoid padding in sensor message structure
firmware: arm_scmi: Fix kernel doc warnings about return values
firmware: arm_scpi: Fix kernel doc warnings
firmware: arm_scmi: Fix kernel doc warnings
firmware: arm_scmi: Fix possible scmi_linux_errmap buffer overflow
firmware: arm_scmi: Ensure drivers provide a probe function
firmware: arm_scmi: Simplify device probe function on the bus
Link: https://lore.kernel.org/r/20210714165831.2617437-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Arm FF-A fixes for v5.14
A small set of fixes:
- adding check for presence of probe while registering the driver to
prevent NULL pointer access
- dropping the duplicate check as the driver core already takes care of it
- fixing possible ffa_linux_errmap buffer overflow and
- fixing kernel-doc warning for comment style
* tag 'arm-ffa-fixes-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_ffa: Fix a possible ffa_linux_errmap buffer overflow
firmware: arm_ffa: Fix the comment style
firmware: arm_ffa: Simplify probe function
firmware: arm_ffa: Ensure drivers provide a probe function
Link: https://lore.kernel.org/r/20210714165806.2617325-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
arm64: tegra: Device tree fixes for v5.14-rc1
This contains two late fixes for Tegra194 device tree files to restore
USB and audio functionality after enabling system-wide IOMMU support.
* tag 'tegra-for-5.14-arm64-dt-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
arm64: tegra: Enable SMMU support for USB on Tegra194
arm64: tegra: Enable audio IOMMU support on Tegra194
Link: https://lore.kernel.org/r/20210709150220.2543875-1-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Memory controller drivers for v5.14 - Tegra SoC, late fixes
Two fixes for recent series of changes in Tegra SoC memory controller
drivers:
1. Add a stub for tegra_mc_probe_device() to fix compile testing of
arm-smmu without TEGRA_MC.
2. Fix arm-smmu dtschema syntax.
* tag 'memory-controller-drv-tegra-5.14-3' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl:
dt-bindings: arm-smmu: Fix json-schema syntax
memory: tegra: Add compile-test stub for tegra_mc_probe_device()
Link: https://lore.kernel.org/r/20210625073604.13562-1-krzysztof.kozlowski@canonical.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Pull documentation fixes from Jonathan Corbet:
"A handful of fixes in and around documentation.
Some funky quotes in LICENSES/dual/CC-BY-4.0 were giving spdxcheck.py
grief; that has been fixed on both ends. Also a couple of features
updates and one docs build fix"
* tag 'docs-5.14-2' of git://git.lwn.net/linux:
docs/zh_CN: add a missing space character
Documentation/features: Add THREAD_INFO_IN_TASK feature matrix
Documentation/features: Update the ARCH_HAS_TICK_BROADCAST entry
LICENSES/dual/CC-BY-4.0: Git rid of "smart quotes"
scripts/spdxcheck.py: Strictly read license files in utf-8
According to reference guides mt7530 (mt7620) and mt7531:
NOTE: When IVL is reset, MAC[47:0] and FID[2:0] will be used to
read/write the address table. When IVL is set, MAC[47:0] and CVID[11:0]
will be used to read/write the address table.
Since the function only fills in CVID and no FID, we need to set the
IVL bit. The existing code does not set it.
This is a fix for the issue I dropped here earlier:
http://lists.infradead.org/pipermail/linux-mediatek/2021-June/025697.html
With this patch, it is now possible to delete the 'self' fdb entry
manually. However, wifi roaming still has the same issue, the entry
does not get deleted automatically. Wifi roaming also needs a fix
somewhere else to function correctly in combination with vlan.
Signed-off-by: Eric Woudstra <ericwouds@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull block fixes from Jens Axboe:
- NVMe fixes via Christoph:
- fix various races in nvme-pci when shutting down just after
probing (Casey Chen)
- fix a net_device leak in nvme-tcp (Prabhakar Kushwaha)
- Fix regression in xen-blkfront by cleaning up the removal state
machine (Christoph)
- Fix tag_set and queue cleanup ordering regression in nbd (Wang)
- Fix tag_set and queue cleanup ordering regression in pd (Guoqing)
* tag 'block-5.14-2021-07-16' of git://git.kernel.dk/linux-block:
xen-blkfront: sanitize the removal state machine
nbd: fix order of cleaning up the queue and freeing the tagset
pd: fix order of cleaning up the queue and freeing the tagset
nvme-pci: do not call nvme_dev_remove_admin from nvme_remove
nvme-pci: fix multiple races in nvme_setup_io_queues
nvme-tcp: use __dev_get_by_name instead dev_get_by_name for OPT_HOST_IFACE
Pull io_uring fixes from Jens Axboe:
"Two small fixes: one fixing the process target of a check, and the
other a minor issue with the drain error handling"
* tag 'io_uring-5.14-2021-07-16' of git://git.kernel.dk/linux-block:
io_uring: fix io_drain_req()
io_uring: use right task for exiting checks
As Alexander points out, when we are trying to recycle a cloned/expanded
SKB we might trigger a race. The recycling code relies on the
pp_recycle bit to trigger, which we carry over to cloned SKBs.
If that cloned SKB gets expanded or if we get references to the frags,
call skb_release_data() and overwrite skb->head, we are creating separate
instances accessing the same page frags. Since the skb_release_data()
will first try to recycle the frags, there's a potential race between
the original and cloned SKB, since both will have the pp_recycle bit set.
Fix this by explicitly those SKBs not recyclable.
The atomic_sub_return effectively limits us to a single release case,
and when we are calling skb_release_data we are also releasing the
option to perform the recycling, or releasing the pages from the page pool.
Fixes: 6a5bcd84e8 ("page_pool: Allow drivers to hint on SKB recycling")
Reported-by: Alexander Duyck <alexanderduyck@fb.com>
Suggested-by: Alexander Duyck <alexanderduyck@fb.com>
Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull zonefs fix from Damien Le Moal:
"A single patch to remove an unnecessary NULL bio check (from
Xianting)"
* tag 'zonefs-5.14-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/zonefs:
zonefs: remove redundant null bio check
Commit 72a7cf0aec ("drm/amd/display: Keep linebuffer pixel depth at
30bpp for DCE-11.0.") doesn't seems to have fixed 10bit 4K rendering over
DisplayPort for CIK GPUs. On my machine with a HAWAII GPU I get a broken
image that looks like it has an effective resolution of 1920x1080 but
scaled up in an irregular way. Reverting the commit or applying this
patch fixes the problem on v5.14-rc1.
Fixes: 72a7cf0aec ("drm/amd/display: Keep linebuffer pixel depth at 30bpp for DCE-11.0.")
Acked-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Liviu Dudau <liviu@dudau.co.uk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Pull drm fixes from Dave Airlie:
"Regular rc2 fixes though a bit more than usual at rc2 stage, people
must have been testing early or else some fixes from last week got a
bit laggy.
There is one larger change in the amd fixes to amalgamate some power
management code on the newer chips with the code from the older chips,
it should only affects chips where support was introduced in rc1 and
it should make future fixes easier to maintain probably a good idea to
merge it now.
Otherwise it's mostly fixes across the board.
dma-buf:
- Fix fence leak in sync_file_merge() error code
drm/panel:
- nt35510: Don't fail on DSI reads
fbdev:
- Avoid use-after-free by not deleting current video mode
ttm:
- Avoid NULL-ptr deref in ttm_range_man_fini()
vmwgfx:
- Fix a merge commit
qxl:
- fix a TTM regression
amdgpu:
- SR-IOV fixes
- RAS fixes
- eDP fixes
- SMU13 code unification to facilitate fixes in the future
- Add new renoir DID
- Yellow Carp fixes
- Beige Goby fixes
- Revert a bunch of TLB fixes that caused regressions
- Revert an LTTPR display regression
amdkfd
- Fix VRAM access regression
- SVM fixes
i915:
- Fix -EDEADLK handling regression
- Drop the page table optimisation"
* tag 'drm-fixes-2021-07-16' of git://anongit.freedesktop.org/drm/drm: (29 commits)
drm/amdgpu: add another Renoir DID
drm/ttm: add a check against null pointer dereference
drm/i915/gtt: drop the page table optimisation
drm/i915/gt: Fix -EDEADLK handling regression
drm/amd/pm: Add waiting for response of mode-reset message for yellow carp
Revert "drm/amdkfd: Add heavy-weight TLB flush after unmapping"
Revert "drm/amdgpu: Add table_freed parameter to amdgpu_vm_bo_update"
Revert "drm/amdkfd: Make TLB flush conditional on mapping"
Revert "drm/amdgpu: Fix warning of Function parameter or member not described"
Revert "drm/amdkfd: Add memory sync before TLB flush on unmap"
drm/amd/pm: Fix BACO state setting for Beige_Goby
drm/amdgpu: Restore msix after FLR
drm/amdkfd: Allow CPU access for all VRAM BOs
drm/amdgpu/display - only update eDP's backlight level when necessary
drm/amdkfd: handle fault counters on invalid address
drm/amdgpu: Correct the irq numbers for virtual crtc
drm/amd/display: update header file name
drm/amd/pm: drop smu_v13_0_1.c|h files for yellow carp
drm/amd/display: remove faulty assert
Revert "drm/amd/display: Always write repeater mode regardless of LTTPR"
...
Pull RCU fixes from Paul McKenney:
- fix regressions induced by a merge-window change in scheduler
semantics, which means that smp_processor_id() can no longer be used
in kthreads using simple affinity to bind themselves to a specific
CPU.
- fix a bug in Tasks Trace RCU that was thought to be strictly
theoretical. However, production workloads have started hitting this,
so these fixes need to be merged sooner rather than later.
- fix a minor printk()-format-mismatch issue introduced during the
merge window.
* 'urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu:
rcu: Fix pr_info() formats and values in show_rcu_gp_kthreads()
rcu-tasks: Don't delete holdouts within trc_wait_for_one_reader()
rcu-tasks: Don't delete holdouts within trc_inspect_reader()
refscale: Avoid false-positive warnings in ref_scale_reader()
scftorture: Avoid false-positive warnings in scftorture_invoker()
cadence-quadspi has a builtin Auto-HW polling funtionality using which
it keep tracks of completion of write operations. When Auto-HW polling
is enabled, it automatically initiates status register read operation,
until the flash clears its busy bit.
cadence-quadspi controller doesn't allow an address phase when
auto-polling the busy bit on the status register. Unlike SPI NOR
flashes, SPI NAND flashes do require the address of status register
when polling the busy bit using the read register operation. As
Auto-HW polling is enabled by default, cadence-quadspi returns a
timeout for every write operation after an indefinite amount of
polling on SPI NAND flashes.
Disable Auto-HW polling completely as the spi-nor core, spinand core,
etc. take care of polling the busy bit on their own.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Link: https://lore.kernel.org/r/20210713125743.1540-2-a-nandan@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Refactor the permission check in perf_event_open() into a helper
perf_check_permission(). This makes the permission check logic more
readable (because we no longer have a negated disjunction). Add a
comment mentioning the ptrace check also checks the uid.
No functional change intended.
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Link: https://lore.kernel.org/r/20210705084453.2151729-2-elver@google.com
If perf_event_open() is called with another task as target and
perf_event_attr::sigtrap is set, and the target task's user does not
match the calling user, also require the CAP_KILL capability or
PTRACE_MODE_ATTACH permissions.
Otherwise, with the CAP_PERFMON capability alone it would be possible
for a user to send SIGTRAP signals via perf events to another user's
tasks. This could potentially result in those tasks being terminated if
they cannot handle SIGTRAP signals.
Note: The check complements the existing capability check, but is not
supposed to supersede the ptrace_may_access() check. At a high level we
now have:
capable of CAP_PERFMON and (CAP_KILL if sigtrap)
OR
ptrace_may_access(...) // also checks for same thread-group and uid
Fixes: 97ba62b278 ("perf: Add support for SIGTRAP on perf events")
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org> # 5.13+
Link: https://lore.kernel.org/r/20210705084453.2151729-1-elver@google.com
The soft_limit and hard_limit in the function efi_load_initrd describes
the preferred and max address of initrd loading location respectively.
However, the description wrongly describes it as the size of the
allocated memory.
Fix the function description.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
kexec_load_file() relies on the memblock infrastructure to avoid
stamping over regions of memory that are essential to the survival
of the system.
However, nobody seems to agree how to flag these regions as reserved,
and (for example) EFI only publishes its reservations in /proc/iomem
for the benefit of the traditional, userspace based kexec tool.
On arm64 platforms with GICv3, this can result in the payload being
placed at the location of the LPI tables. Shock, horror!
Let's augment the EFI reservation code with a memblock_reserve() call,
protecting our dear tables from the secondary kernel invasion.
Reported-by: Moritz Fischer <mdf@kernel.org>
Tested-by: Moritz Fischer <mdf@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Missing TPM final event log table is not a firmware bug.
Clearly if providing event log in the old format makes the final event
log invalid it should not be provided at least in that case.
Fixes: b4f1874c62 ("tpm: check event log version before reading final events")
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Fix below division by zero warning:
- The reason for dividing by zero is because the dummy bus width is zero,
but if the dummy n bytes is zero, it indicates that there is no data transfer,
so we can just return zero without doing any calculations.
[ 0.795337] Division by zero in kernel.
:
[ 0.834051] [<807fd40c>] (__div0) from [<804e1acc>] (Ldiv0+0x8/0x10)
[ 0.839097] [<805f0710>] (cqspi_exec_mem_op) from [<805edb4c>] (spi_mem_exec_op+0x3b0/0x3f8)
Fixes: 7512eaf541 ("spi: cadence-quadspi: Fix dummy cycle calculation when buswidth > 1")
Signed-off-by: Yoshitaka Ikeda <ikeda@nskint.co.jp>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/92eea403-9b21-2488-9cc1-664bee760c5e@nskint.co.jp
Signed-off-by: Mark Brown <broonie@kernel.org>
Add several test cases for checking update_alu_sanitation_state() under
multiple paths:
# ./test_verifier
[...]
#1061/u map access: known scalar += value_ptr unknown vs const OK
#1061/p map access: known scalar += value_ptr unknown vs const OK
#1062/u map access: known scalar += value_ptr const vs unknown OK
#1062/p map access: known scalar += value_ptr const vs unknown OK
#1063/u map access: known scalar += value_ptr const vs const (ne) OK
#1063/p map access: known scalar += value_ptr const vs const (ne) OK
#1064/u map access: known scalar += value_ptr const vs const (eq) OK
#1064/p map access: known scalar += value_ptr const vs const (eq) OK
#1065/u map access: known scalar += value_ptr unknown vs unknown (eq) OK
#1065/p map access: known scalar += value_ptr unknown vs unknown (eq) OK
#1066/u map access: known scalar += value_ptr unknown vs unknown (lt) OK
#1066/p map access: known scalar += value_ptr unknown vs unknown (lt) OK
#1067/u map access: known scalar += value_ptr unknown vs unknown (gt) OK
#1067/p map access: known scalar += value_ptr unknown vs unknown (gt) OK
[...]
Summary: 1762 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
In 7fedb63a83 ("bpf: Tighten speculative pointer arithmetic mask") we
narrowed the offset mask for unprivileged pointer arithmetic in order to
mitigate a corner case where in the speculative domain it is possible to
advance, for example, the map value pointer by up to value_size-1 out-of-
bounds in order to leak kernel memory via side-channel to user space.
The verifier's state pruning for scalars leaves one corner case open
where in the first verification path R_x holds an unknown scalar with an
aux->alu_limit of e.g. 7, and in a second verification path that same
register R_x, here denoted as R_x', holds an unknown scalar which has
tighter bounds and would thus satisfy range_within(R_x, R_x') as well as
tnum_in(R_x, R_x') for state pruning, yielding an aux->alu_limit of 3:
Given the second path fits the register constraints for pruning, the final
generated mask from aux->alu_limit will remain at 7. While technically
not wrong for the non-speculative domain, it would however be possible
to craft similar cases where the mask would be too wide as in 7fedb63a83.
One way to fix it is to detect the presence of unknown scalar map pointer
arithmetic and force a deeper search on unknown scalars to ensure that
we do not run into a masking mismatch.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Follow-up to fe9a5ca7e3 ("bpf: Do not mark insn as seen under speculative
path verification"). The sanitize_insn_aux_data() helper does not serve a
particular purpose in today's code. The original intention for the helper
was that if function-by-function verification fails, a given program would
be cleared from temporary insn_aux_data[], and then its verification would
be re-attempted in the context of the main program a second time.
However, a failure in do_check_subprogs() will skip do_check_main() and
propagate the error to the user instead, thus such situation can never occur.
Given its interaction is not compatible to the Spectre v1 mitigation (due to
comparing aux->seen with env->pass_cnt), just remove sanitize_insn_aux_data()
to avoid future bugs in this area.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
On stream stop, currently CPU DAI stop sequence invoked first
followed by DMA. For Few platforms, it is required to stop the
DMA first before stopping CPU DAI.
Introduced new flag in dai_link structure for reordering stop sequence.
Based on flag check, ASoC core will re-order the stop sequence.
Fixes: 4378f1fbe9 ("ASoC: soc-pcm: Use different sequence for start/stop trigger")
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://lore.kernel.org/r/20210716123015.15697-1-vijendar.mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
