Jonathan Calmels from NVIDIA reported that he's able to bypass the
mount visibility security check in place in the Linux kernel by using
a combination of the unbindable property along with the private mount
propagation option to allow a unprivileged user to see a path which
was purposefully hidden by the root user.
Reproducer:
# Hide a path to all users using a tmpfs
root@castiana:~# mount -t tmpfs tmpfs /sys/devices/
root@castiana:~#
# As an unprivileged user, unshare user namespace and mount namespace
stgraber@castiana:~$ unshare -U -m -r
# Confirm the path is still not accessible
root@castiana:~# ls /sys/devices/
# Make /sys recursively unbindable and private
root@castiana:~# mount --make-runbindable /sys
root@castiana:~# mount --make-private /sys
# Recursively bind-mount the rest of /sys over to /mnnt
root@castiana:~# mount --rbind /sys/ /mnt
# Access our hidden /sys/device as an unprivileged user
root@castiana:~# ls /mnt/devices/
breakpoint cpu cstate_core cstate_pkg i915 intel_pt isa kprobe
LNXSYSTM:00 msr pci0000:00 platform pnp0 power software system
tracepoint uncore_arb uncore_cbox_0 uncore_cbox_1 uprobe virtual
Solve this by teaching copy_tree to fail if a mount turns out to be
both unbindable and locked.
Cc: <email address hidden>
Fixes: 5ff9d8a65ce8 ("vfs: Lock in place mounts from more privileged users")
Reported-by: Jonathan Calmels <email address hidden>
Signed-off-by: "Eric W. Biederman" <email address hidden>
(cherry picked from commit df7342b240185d58d3d9665c0bbf0a0f5570ec29)
Signed-off-by: Tyler Hicks <email address hidden>
Acked-by: Colin King <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
It was recently pointed out that the one instance of testing MNT_LOCKED
outside of the namespace_sem is in ksys_umount.
Fix that by adding a test inside of do_umount with namespace_sem and
the mount_lock held. As it helps to fail fails the existing test is
maintained with an additional comment pointing out that it may be racy
because the locks are not held.
Cc: <email address hidden>
Reported-by: Al Viro <email address hidden>
Fixes: 5ff9d8a65ce8 ("vfs: Lock in place mounts from more privileged users")
Signed-off-by: "Eric W. Biederman" <email address hidden>
(cherry picked from commit 25d202ed820ee347edec0bf3bf553544556bf64b)
Signed-off-by: Tyler Hicks <email address hidden>
Acked-by: Colin King <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Recently was noticed in an HP GEN9 system that kdump couldn't succeed
due to an irq storm coming from an Intel NIC, narrowed down to be lack
of clearing the MSI/MSI-X enable bits during the kdump kernel boot.
For that, we need an early quirk to manually turn off MSI/MSI-X for
PCI devices - this was worked as an optional boot parameter in a
(~subsequent~) previous patch.
Problem is that in our test system, the Intel NICs were not present in
any secondary bus under the first PCIe root complex, so they couldn't
be reached by the recursion in check_dev_quirk(). Modern systems,
specially with multi-processors and multiple NUMA nodes expose multiple
root complexes, describing more than one PCI hierarchy domain. Currently
the simple recursion present in the early-quirks code from x86 starts a
descending recursion from bus 0000:00, and reach many other busses by
navigating this hierarchy walking through the bridges. This is not
enough in systems with more than one root complex/host bridge, since
the recursion won't "traverse" to other root complexes by starting
statically in 0000:00 (for more details, see [0]).
This patch hence implements the full bus/device/function scan in
early_quirks(), by checking all possible busses instead of using a
recursion based on the first root bus or limiting the search scope to
the first 32 busses (like it was done in the beginning [1]).
[1] From historical perspective, early PCI scan dates back
to BitKeeper, added by Andi Kleen's "[PATCH] APIC fixes for x86-64",
on October/2003. It initially restricted the search to the first
32 busses and slots.
Due to a potential bug found in Nvidia chipsets, the scan
was changed to run only in the first root bus: see
commit 8659c406ade3 ("x86: only scan the root bus in early PCI quirks")
Finally, secondary busses reachable from the 1st bus were re-added back by:
commit 850c321027c2 ("x86/quirks: Reintroduce scanning of secondary buses")
Reported-by: Dan Streetman <email address hidden>
Signed-off-by: Guilherme G. Piccoli <email address hidden>
[mfo: v2:
- gate the bus-scan differences with the cmdline option.
- update changelog: subsequent/previous patch.]
Signed-off-by: Mauricio Faria de Oliveira <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
We observed a kdump failure in x86 that was narrowed down to MSI irq
storm coming from a PCI network device. The bug manifests as a lack of
progress in the boot process of kdump kernel, and a flood of kernel
messages like:
[...]
[ 342.265294] do_IRQ: 0.155 No irq handler for vector
[ 342.266916] do_IRQ: 0.155 No irq handler for vector
[ 347.258422] do_IRQ: 14053260 callbacks suppressed
[...]
The root cause of the issue is that kexec process of the kdump kernel
doesn't ensure PCI devices are reset or MSI capabilities are disabled,
so a PCI adapter could produce a huge amount of irqs which would steal
all the processing time for the CPU (specially since we usually restrict
kdump kernel to use a single CPU only).
This patch implements the kernel parameter "pci=clearmsi" to clear the
MSI/MSI-X enable bits in the Message Control register for all PCI devices
during early boot time, thus preventing potential issues in the kexec'ed
kernel. PCI spec also supports/enforces this need (see PCI Local Bus
spec sections 6.8.1.3 and 6.8.2.3).
Suggested-by: Dan Streetman <email address hidden>
Suggested-by: Gavin Shan <email address hidden>
Signed-off-by: Guilherme G. Piccoli <email address hidden>
[mfo: backport to ubuntu-xenial:
- different path for Documentation/.../kernel-parameters.txt
- update context lines in pci-direct.h and early-quirks.c]
Signed-off-by: Mauricio Faria de Oliveira <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
This patch exports (and renames) the function find_cap() to be used
in the early PCI quirk code, by the next patch.
This is being moved out from AGP code to generic early-PCI code
since it's not AGP-specific and can be used for any PCI device.
No functional changes intended.
Signed-off-by: Guilherme G. Piccoli <email address hidden>
Signed-off-by: Mauricio Faria de Oliveira <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
In ena_remove() we have the following stack call:
ena_remove()
unregister_netdev()
ena_destroy_device()
netif_carrier_off()
Calling netif_carrier_off() causes linkwatch to try to handle the
link change event on the already unregistered netdev, which leads
to a read from an unreadable memory address.
This patch switches the order of the two functions, so that
netif_carrier_off() is called on a regiestered netdev.
To accomplish this fix we also had to:
1. Remove the set bit ENA_FLAG_TRIGGER_RESET
2. Add a sanitiy check in ena_close()
both to prevent double device reset (when calling unregister_netdev()
ena_close is called, but the device was already deleted in
ena_destroy_device()).
3. Set the admin_queue running state to false to avoid using it after
device was reset (for example when calling ena_destroy_all_io_queues()
right after ena_com_dev_reset() in ena_down)
Implement pci_acpi_scan_root() and other arch-specific calls so ARM64 can
use ACPI to setup and enumerate PCI buses.
Use memory-mapped configuration space information from either the ACPI
_CBA method or the MCFG table and the ECAM library and generic ECAM config
accessor ops.
Implement acpi_pci_bus_find_domain_nr() to retrieve the domain number from
the acpi_pci_root structure.
Implement pcibios_add_bus() and pcibios_remove_bus() to call
acpi_pci_add_bus() and acpi_pci_remove_bus() for ACPI slot management and
other configuration.
Signed-off-by: Tomasz Nowicki <email address hidden>
Signed-off-by: Jayachandran C <email address hidden>
Signed-off-by: Bjorn Helgaas <email address hidden>
Reviewed-by: Lorenzo Pieralisi <email address hidden>
(backported from commit 0cb0786bac159ee4c983abab51093ef623849afa)
[ dannf: Kconfig offset fixup ]
Signed-off-by: dann frazier <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
26780ee...
by
Tomasz Nowicki <email address hidden>
ARM64: PCI: ACPI support for legacy IRQs parsing and consolidation with DT code
To enable PCI legacy IRQs on platforms booting with ACPI, arch code should
include ACPI-specific callbacks that parse and set-up the device IRQ
number, equivalent to the DT boot path. Owing to the current ACPI core scan
handlers implementation, ACPI PCI legacy IRQs bindings cannot be parsed at
device add time, since that would trigger ACPI scan handlers ordering
issues depending on how the ACPI tables are defined.
To solve this problem and consolidate FW PCI legacy IRQs parsing in one
single pcibios callback (pending final removal), this patch moves DT PCI
IRQ parsing to the pcibios_alloc_irq() callback (called by PCI core code at
driver probe time) and adds ACPI PCI legacy IRQs parsing to the same
callback too, so that FW PCI legacy IRQs parsing is confined in one single
arch callback that can be easily removed when code parsing PCI legacy IRQs
is consolidated and moved to core PCI code.
Suggested-by: Lorenzo Pieralisi <email address hidden>
Signed-off-by: Tomasz Nowicki <email address hidden>
Signed-off-by: Bjorn Helgaas <email address hidden>
(cherry picked from commit d8ed75d593321c80ccd92f9dba218e90286bde16)
Signed-off-by: dann frazier <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
de7e48b...
by
Tomasz Nowicki <email address hidden>
pci_bus_find_domain_nr() retrieves the host bridge domain number in a
DT-specific way. Rename it to of_pci_bus_find_domain_nr() to reflect that,
so we can add a corresponding function for ACPI.
[bhelgaas: changelog]
Signed-off-by: Tomasz Nowicki <email address hidden>
Signed-off-by: Bjorn Helgaas <email address hidden>
Reviewed-by: Lorenzo Pieralisi <email address hidden>
(cherry picked from commit 1a4f93f7112fd92383534f4c23d7b24fd4f8833c)
Signed-off-by: dann frazier <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
