[ Upstream commit 16b8fe4caf ]
In case an error occurs in vfio_pci_enable() before the call to
vfio_pci_probe_mmaps(), vfio_pci_disable() will try to iterate
on an uninitialized list and cause a kernel panic.
Lets move to the initialization to vfio_pci_probe() to fix the
issue.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Fixes: 05f0c03fba ("vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive")
CC: Stable <stable@vger.kernel.org> # v4.7+
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 76786a0f08 upstream.
As described in "fscrypt: add fscrypt_is_nokey_name()", it's possible to
create a duplicate filename in an encrypted directory by creating a file
concurrently with adding the directory's encryption key.
Fix this bug on ubifs by rejecting no-key dentries in ubifs_create(),
ubifs_mkdir(), ubifs_mknod(), and ubifs_symlink().
Note that ubifs doesn't actually report the duplicate filenames from
readdir, but rather it seems to replace the original dentry with a new
one (which is still wrong, just a different effect from ext4).
On ubifs, this fixes xfstest generic/595 as well as the new xfstest I
wrote specifically for this bug.
Fixes: f4f61d2cc6 ("ubifs: Implement encrypted filenames")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201118075609.120337-5-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bfc2b7e851 upstream.
As described in "fscrypt: add fscrypt_is_nokey_name()", it's possible to
create a duplicate filename in an encrypted directory by creating a file
concurrently with adding the directory's encryption key.
Fix this bug on f2fs by rejecting no-key dentries in f2fs_add_link().
Note that the weird check for the current task in f2fs_do_add_link()
seems to make this bug difficult to reproduce on f2fs.
Fixes: 9ea97163c6 ("f2fs crypto: add filename encryption for f2fs_add_link")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201118075609.120337-4-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 75d18cd186 upstream.
As described in "fscrypt: add fscrypt_is_nokey_name()", it's possible to
create a duplicate filename in an encrypted directory by creating a file
concurrently with adding the directory's encryption key.
Fix this bug on ext4 by rejecting no-key dentries in ext4_add_entry().
Note that the duplicate check in ext4_find_dest_de() sometimes prevented
this bug. However in many cases it didn't, since ext4_find_dest_de()
doesn't examine every dentry.
Fixes: 4461471107 ("ext4 crypto: enable filename encryption")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201118075609.120337-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 159e1de201 upstream.
It's possible to create a duplicate filename in an encrypted directory
by creating a file concurrently with adding the encryption key.
Specifically, sys_open(O_CREAT) (or sys_mkdir(), sys_mknod(), or
sys_symlink()) can lookup the target filename while the directory's
encryption key hasn't been added yet, resulting in a negative no-key
dentry. The VFS then calls ->create() (or ->mkdir(), ->mknod(), or
->symlink()) because the dentry is negative. Normally, ->create() would
return -ENOKEY due to the directory's key being unavailable. However,
if the key was added between the dentry lookup and ->create(), then the
filesystem will go ahead and try to create the file.
If the target filename happens to already exist as a normal name (not a
no-key name), a duplicate filename may be added to the directory.
In order to fix this, we need to fix the filesystems to prevent
->create(), ->mkdir(), ->mknod(), and ->symlink() on no-key names.
(->rename() and ->link() need it too, but those are already handled
correctly by fscrypt_prepare_rename() and fscrypt_prepare_link().)
In preparation for this, add a helper function fscrypt_is_nokey_name()
that filesystems can use to do this check. Use this helper function for
the existing checks that fs/crypto/ does for rename and link.
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201118075609.120337-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 93decc5636 upstream.
In __make_request() a new r10bio is allocated and passed to
raid10_read_request(). The read_slot member of the bio is not
initialized, and the raid10_read_request() uses it to index an
array. This leads to occasional panics.
Fix by initializing the field to invalid value and checking for
valid value in raid10_read_request().
Cc: stable@vger.kernel.org
Signed-off-by: Kevin Vigor <kvigor@gmail.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1/ enable sii902x
Add RGB/BT1120 to HDMI support, this is needed by
rk3568-evb2-lp4x-v10-bt1120-to-hdmi.
2/ enable CONFIG_SDIO_KEEPALIVE
This is needed by RK356X EVB to support Wi-Fi.
3/ add rockchip ebc dev driver.
4/ remove unused CONFIG_I2C_MUX.
5/ enable CONFIG_PCIE_DW_ROCKCHIP for PCIE devices.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Change-Id: I3076aefab88fa2b166a8af89e8681fa46a69e7f9
RK356x SDK will power off logic and grf module in suspend.
So we don't need to enable device wakeup for rk356x usb host
to keep usb controller PD on. With this patch, it can call
rk356x combphy init by usb_phy_roothub_init during resume,
and fix the usb3.0 host function failure after resume.
Change-Id: I40f9a34b5f2aaeede833f9e46153f60b767ea3f0
Signed-off-by: William Wu <william.wu@rock-chips.com>
If get_acc_dev() fails to obtain a reference to the current device,
acc_disconnect() will attempt to put_acc_dev() with the resulting NULL
pointer, leading to a crash:
| Unable to handle kernel NULL pointer dereference at virtual address 00000074
| [...]
| [<c0abb288>] (acc_disconnect) from [<c0a91a38>] (android_disconnect+0x1c/0x7c)
| [<c0a91a38>] (android_disconnect) from [<c0a93958>] (usb_gadget_udc_reset+0x10/0x34)
| [<c0a93958>] (usb_gadget_udc_reset) from [<c0a4a9c4>] (dwc3_gadget_reset_interrupt+0x88/0x4fc)
| [<c0a4a9c4>] (dwc3_gadget_reset_interrupt) from [<c0a491f8>] (dwc3_process_event_buf+0x60/0x3e4)
| [<c0a491f8>] (dwc3_process_event_buf) from [<c0a49180>] (dwc3_thread_interrupt+0x24/0x3c)
| [<c0a49180>] (dwc3_thread_interrupt) from [<c02b3404>] (irq_thread_fn+0x1c/0x58)
| [<c02b3404>] (irq_thread_fn) from [<c02b326c>] (irq_thread+0x1ec/0x2f4)
| [<c02b326c>] (irq_thread) from [<c0260804>] (kthread+0x1a8/0x1ac)
| [<c0260804>] (kthread) from [<c0200138>] (ret_from_fork+0x14/0x3c)
Follow the pattern used elsewhere, and return early if we fail to obtain
a reference.
Bug: 173789633
Reported-by: YongQin Liu <yongqin.liu@linaro.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I37a2bff5bc1b6b8269788d08191181763bf0e896
Signed-off-by: Giuliano Procida <gprocida@google.com>
Using bitfields for shared variables is a "bad idea", as they require
a non-atomic read-modify-write to be generated by the compiler, which can
cause updates to unrelated bits in the same word to disappear.
Ensure the 'online' and 'disconnected' members of 'struct acc_dev' are
placed in separate variables by declaring them each as 'int'.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ia6031d82a764e83b2cc3502fbe5fb273511da752
Signed-off-by: Giuliano Procida <gprocida@google.com>
Tearing down and freeing the 'acc_dev' structure when there is
potentially asynchronous work queued involving its member fields is
likely to lead to use-after-free issues.
Cancel any pending work before freeing the structure.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I68a91274aea18034637b738d558d043ac74fadf4
Signed-off-by: Giuliano Procida <gprocida@google.com>
If acc_setup() is called when there is already an allocated instance,
misc_register() will fail but the error path leaves a dangling pointer
to freed memory in the global 'acc_dev' state.
Fix this by ensuring that the refcount is zero before we start, and then
using a cmpxchg() from NULL to serialise any concurrent initialisers.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I2c26289dcce7dbc493964516c49b05d04aaa6839
Signed-off-by: Giuliano Procida <gprocida@google.com>
acc_release() attempts to synchronise with acc_open() using an atomic
'open_excl' member in 'struct acc_dev'. Unfortunately, acc_release()
prematurely resets this atomic variable to zero, meaning there is a
potential race on 'dev->disconnected':
acc_open() acc_release()
atomic_xchg(open_excl), 0)
atomic_xchg(open_excl, 1)
dev->disconnected = 0; dev->disconnected = 1;
Fix the race by ensuring that the 'disconnected' field is written
before clearing 'open_excl' in acc_release().
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ib9a21f2305f6d70de3e760da62dbfdd66889200a
Signed-off-by: Giuliano Procida <gprocida@google.com>
Add refcounting to track the lifetime of the global 'acc_dev' structure,
as the underlying function directories can be removed while references
still exist to the dev node.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I248408e890d01167706c329146d63b64a6456df6
Signed-off-by: Giuliano Procida <gprocida@google.com>
The '_acc_dev' global variable is a fancy use-after-free factory. Wrap
it in some get()/put() functions in preparation for introducing some
refcounting.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I4c839627648c209341a81efa0c001c8d71b878d4
Signed-off-by: Giuliano Procida <gprocida@google.com>
acc_alloc_inst() assigns to a local 'dev' variable, but then never uses
it. Remove the redundant assignment, and the local variable along with
it.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ide9c2e89fb12b846eb8739b302d1b742fc7eb6b5
Signed-off-by: Giuliano Procida <gprocida@google.com>
Remove some useless print statements, as they can trivially be used to
spam the console and don't report anything meaningful.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I28052010fc3ec033a2c99efeb3f6c919d54d75c2
Signed-off-by: Giuliano Procida <gprocida@google.com>
Neither acc_gadget_bind() nor acc_gadget_register_driver() exist, so
remove the stale comments that refer to them.
Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: If396ba3bcac3ca59c48e5a5faa0a8520534ed625
Signed-off-by: Giuliano Procida <gprocida@google.com>
In case of poweroff charging mode, accessory function instance
is not created and due to this, _acc_dev will be NULL. If target
is connected to Accessory dock in poweroff charging mode, there
is a chance dev pointer is accessed, which is NULL. Hence add a
check before processing control request and return error if it is
NULL.
Bug: 141002587
Change-Id: I4f1deb9d764b8c0bd1d7837cbc43a2933167f568
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Giuliano Procida <gprocida@google.com>
f_accessory: fix CTS test stuck since CTS 9.0.
- Refine acc_read() process.
The data length that user (test program) wants to read is different
from they really requested. This will cause the test flow stuck on the
2nd or the 3rd transfers in accessory test.
(By connecting 2 phones with CtsVerifier.apk and
CtsVerifierUSBCompanion.apk installed.)
Bug: 174729307
Change-Id: I5367c8075ed37534e8bed94b60cc79135ae5aebc
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
Signed-off-by: Giuliano Procida <gprocida@google.com>
If the hdmi color format is set to DRM_HDMI_OUTPUT_YCBCR_HQ or
DRM_HDMI_OUTPUT_YCBCR_LQ when the system boot, The actual color
formats is YUV444/YUV422/YUV420. This leads to misjudgment that
the color format has changed, hdmi will be reset. That cause
display err between kernel logo and bootanimation.
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Change-Id: I5d4784ecb64df82ab40723fddb6aef94cb493c5e
(kbdev->current_freqs[i] > freqs[i]) will be always false becasue kbdev->current_freqs[i]
has been updated to freqs[i], so we need save current_freqs[i] to old_freqs[i].
Change-Id: I3f8a06d474a359cf292460878c53592c4ce1472b
Signed-off-by: Liang Chen <cl@rock-chips.com>
This is an optional property to describe data path mapping.
Change-Id: I99fb91a5d1be2e3ec9c7edac206760f589949df5
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
