-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmA1C0IACgkQONu9yGCS
aT4RYxAAyfmYnpeUM96GDx86zamHX7Zq52YAYP1Noyv2WK6ii7emP//WcNtMMMUX
73k5BIybvtUgHZi8EG0fb25k3duPQ8JJaA98Z8bKq1vogyCpHgcn9eQIZhe9g25K
UYn64LPgv38mjnCr/mODNWfa7rLPwWZEqMFcTf/Gz8TOiNtDMgRA5DhXyljbyZVB
z/OIjJBOb0oQRemM+HHHpgschh6JJV3VfyZWSise9mTYkTkPENRUFwYE2g567TD+
Sn9jAsIWS+4y52IWC4BLFGeDkfOuVwzXwR9uJdHa5xdOuvHrM2s8bknn8gcfKo8u
Fh8KC/n+ZPiNi0IoRMwL5PZJV+wHHHiBby/o8fPlL9c9B7qglXGWoLMi+YvnCU9q
4tI5Aor8D3ASyqKemCSTogITw12Z36NQEAoTUjmK0zX+gNXUFW9FNf0ATY6axaE5
PTi4bE6RmvJYNZobAmzgm3jDKCHB8Y82jxdTmoGGnghx9jACLfxw7s+0+TqrG8HA
gfGMTblc41Do/8RCwVWMaepBDXTFt78yLpB0RzdOk9rxl+lk9eKLWGmlfbWCbRbT
wTcs9kgRA6c1zV/G6o1KCSsf0IcpX3IKYae9+k615XARtYSV7ZAJ4hLJCJI3QOHy
XqNtPSeAjjCuSzqUnjojlUry4vRmLjgpN3/YSUfx9oLviDfTZlM=
=rp48
-----END PGP SIGNATURE-----
Merge 5.4.100 into android11-5.4-lts
Changes in 5.4.100
KVM: SEV: fix double locking due to incorrect backport
net: qrtr: Fix port ID for control messages
net: bridge: Fix a warning when del bridge sysfs
Xen/x86: don't bail early from clear_foreign_p2m_mapping()
Xen/x86: also check kernel mapping in set_foreign_p2m_mapping()
Xen/gntdev: correct dev_bus_addr handling in gntdev_map_grant_pages()
Xen/gntdev: correct error checking in gntdev_map_grant_pages()
xen/arm: don't ignore return errors from set_phys_to_machine
xen-blkback: don't "handle" error by BUG()
xen-netback: don't "handle" error by BUG()
xen-scsiback: don't "handle" error by BUG()
xen-blkback: fix error handling in xen_blkbk_map()
media: pwc: Use correct device for DMA
btrfs: fix backport of 2175bf57dc952 in 5.4.95
Linux 5.4.100
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9189f8a6e2d7515697c9e13fbde836f5b8acbe5b
There's a mistake in backport of upstream commit 2175bf57dc95 ("btrfs:
fix possible free space tree corruption with online conversion") as
5.4.95 commit e1ae9aab80.
The enum value BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED has been added to the
wrong enum set, colliding with value of BTRFS_FS_QUOTA_ENABLE. This
could cause problems during the tree conversion, where the quotas
wouldn't be set up properly but the related code executed anyway due to
the bit set.
Link: https://lore.kernel.org/linux-btrfs/20210219111741.95DD.409509F4@e16-tech.com
Reported-by: Wang Yugui <wangyugui@e16-tech.com>
CC: stable@vger.kernel.org # 5.4.95+
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 871997bc9e423f05c7da7c9178e62dde5df2a7f8 upstream.
The function uses a goto-based loop, which may lead to an earlier error
getting discarded by a later iteration. Exit this ad-hoc loop when an
error was encountered.
The out-of-memory error path additionally fails to fill a structure
field looked at by xen_blkbk_unmap_prepare() before inspecting the
handle which does get properly set (to BLKBACK_INVALID_HANDLE).
Since the earlier exiting from the ad-hoc loop requires the same field
filling (invalidation) as that on the out-of-memory path, fold both
paths. While doing so, drop the pr_alert(), as extra log messages aren't
going to help the situation (the kernel will log oom conditions already
anyway).
This is XSA-365.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Julien Grall <julien@xen.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7c77474b2d22176d2bfb592ec74e0f2cb71352c9 upstream.
In particular -ENOMEM may come back here, from set_foreign_p2m_mapping().
Don't make problems worse, the more that handling elsewhere (together
with map's status fields now indicating whether a mapping wasn't even
attempted, and hence has to be considered failed) doesn't require this
odd way of dealing with errors.
This is part of XSA-362.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3194a1746e8aabe86075fd3c5e7cf1f4632d7f16 upstream.
In particular -ENOMEM may come back here, from set_foreign_p2m_mapping().
Don't make problems worse, the more that handling elsewhere (together
with map's status fields now indicating whether a mapping wasn't even
attempted, and hence has to be considered failed) doesn't require this
odd way of dealing with errors.
This is part of XSA-362.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5a264285ed1cd32e26d9de4f3c8c6855e467fd63 upstream.
In particular -ENOMEM may come back here, from set_foreign_p2m_mapping().
Don't make problems worse, the more that handling elsewhere (together
with map's status fields now indicating whether a mapping wasn't even
attempted, and hence has to be considered failed) doesn't require this
odd way of dealing with errors.
This is part of XSA-362.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 36bf1dfb8b266e089afa9b7b984217f17027bf35 upstream.
set_phys_to_machine can fail due to lack of memory, see the kzalloc call
in arch/arm/xen/p2m.c:__set_phys_to_machine_multi.
Don't ignore the potential return error in set_foreign_p2m_mapping,
returning it to the caller instead.
This is part of XSA-361.
Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
Cc: stable@vger.kernel.org
Reviewed-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ebee0eab08594b2bd5db716288a4f1ae5936e9bc upstream.
Failure of the kernel part of the mapping operation should also be
indicated as an error to the caller, or else it may assume the
respective kernel VA is okay to access.
Furthermore gnttab_map_refs() failing still requires recording
successfully mapped handles, so they can be unmapped subsequently. This
in turn requires there to be a way to tell full hypercall failure from
partial success - preset map_op status fields such that they won't
"happen" to look as if the operation succeeded.
Also again use GNTST_okay instead of implying its value (zero).
This is part of XSA-361.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dbe5283605b3bc12ca45def09cc721a0a5c853a2 upstream.
We may not skip setting the field in the unmap structure when
GNTMAP_device_map is in use - such an unmap would fail to release the
respective resources (a page ref in the hypervisor). Otoh the field
doesn't need setting at all when GNTMAP_device_map is not in use.
To record the value for unmapping, we also better don't use our local
p2m: In particular after a subsequent change it may not have got updated
for all the batch elements. Instead it can simply be taken from the
respective map's results.
We can additionally avoid playing this game altogether for the kernel
part of the mappings in (x86) PV mode.
This is part of XSA-361.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: stable@vger.kernel.org
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b512e1b077e5ccdbd6e225b15d934ab12453b70a upstream.
We should not set up further state if either mapping failed; paying
attention to just the user mapping's status isn't enough.
Also use GNTST_okay instead of implying its value (zero).
This is part of XSA-361.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a35f2ef3b7376bfd0a57f7844bd7454389aae1fc upstream.
Its sibling (set_foreign_p2m_mapping()) as well as the sibling of its
only caller (gnttab_map_refs()) don't clean up after themselves in case
of error. Higher level callers are expected to do so. However, in order
for that to really clean up any partially set up state, the operation
should not terminate upon encountering an entry in unexpected state. It
is particularly relevant to notice here that set_foreign_p2m_mapping()
would skip setting up a p2m entry if its grant mapping failed, but it
would continue to set up further p2m entries as long as their mappings
succeeded.
Arguably down the road set_foreign_p2m_mapping() may want its page state
related WARN_ON() also converted to an error return.
This is part of XSA-361.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: stable@vger.kernel.org
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit ae068f561baa003d260475c3e441ca454b186726 ]
The port ID for control messages was uncorrectly set with broadcast
node ID value, causing message to be dropped on remote side since
not passing packet filtering (cb->dst_port != QRTR_PORT_CTRL).
Fixes: d27e77a3de ("net: qrtr: Reset the node and port ID of broadcast messages")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fix an incorrect line in the 5.4.y and 4.19.y backports of commit
19a23da53932bc ("Fix unsynchronized access to sev members through
svm_register_enc_region"), first applied to 5.4.98 and 4.19.176.
Fixes: 1e80fdc09d ("KVM: SVM: Pin guest memory when SEV is active")
Reported-by: Dov Murik <dovmurik@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org # 5.4.x
Cc: stable@vger.kernel.org # 4.19.x
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sync up with android11-5.4 for the following commits:
29b2beadc6 ANDROID: GKI: update Sony KMI symbol list
c382bf8373 ANDROID: ABI updates for db845c (enabling wifi)
2ae7c28a04 ANDROID: db845c_gki.fragment: Enable wifi on db845c w/ android-5.4
8f96c722f5 UPSTREAM: arm64: dts: qcom: sdm845: Add APSS watchdog node
1d2d51a301 UPSTREAM: arm64: dts: qcom: db845c: Move remoteproc firmware to sdm845
a09a63360b UPSTREAM: ath10k: qmi: Sleep for a while before assigning MSA memory
2d00c82d25 UPSTREAM: soc: qcom: qmi: Return EPROBE_DEFER if no address family
240e180bd8 ANDROID: ABI: Update allowed list for QCOM
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id6775586a5097a7276f9c6c0cb507cabde071e1c
Add config settings to enable wifi via modules on db845c
Bug: 146449535
Change-Id: I81892c4cc48db7839fe99aa5fb0b0a0782cab321
Signed-off-by: John Stultz <john.stultz@linaro.org>
commit ef8576789e869b7584684ae81126a465eb1deeb6 upstream.
Add a node describing the watchdog found in the application subsystem.
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
(cherry picked from commit ef8576789e869b7584684ae81126a465eb1deeb6)
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: I835d512c13c392e356c5190e865c0617e97041c2
The redistributable firmware should work on any engineering device, so
lets push this to qcom/sdm845, rather than qcom/db845c. Also specify the
path for the modem firmware.
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20191113203951.3704428-1-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
(cherry picked from commit 82b1cc447a2c7c5121ce34f15f9840110ee3499f)
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: Ica785dd7faee17dce933379dbb6ada32a3697bdb
commit b70b3a36ec33a2c8d3292f3b33fe2047a8f57b9a upstream.
Unless we sleep for a while before transitioning the MSA memory to WLAN
the MPSS.AT.4.0.c2-01184-SDM845_GEN_PACK-1 firmware triggers a security
violation fairly reliably. Unforutnately recovering from this failure
always results in the entire system freezing.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit b70b3a36ec33a2c8d3292f3b33fe2047a8f57b9a)
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: Ie44e86d404f1897b7cc349a03972178374fef89c
If a client comes up early in the boot process (perhaps was a built-in
driver), qmi_handle_init() will likely fail with a EAFNOSUPPORT since the
underlying ipc router hasn't init'd and registered the address family.
This should not be a fatal error since chances are, the router will come
up later, so recode the error to EPROBE_DEFER so that clients will retry
later.
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Link: https://lore.kernel.org/r/20191106230511.1290-1-jeffrey.l.hugo@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
(cherry picked from commit 52af26e33e700158e6549f1465fcf9da099fabfa)
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: I26a0dabe9b1f3b8e9cc793f7f52ee8f658ecdce3
Add the following symbols to QCOM allowed-list:
-- pcie_bus_configure_settings
Bug: 180475310
Change-Id: I49ed1ada673a9199370344cf2b89d7369f92d3f2
Signed-off-by: Tony Truong <truong@codeaurora.org>
Sync up with android11-5.4 for the following commits:
224ea2cd2c ANDROID: GKI: update Sony symbol list for texfat
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I445c062f76e9ca7e0345b5663fc9b17c5e3609ba
Because the .xml file can not handle being "merged" we had to pick one
side or the other in commit 56f4fac695 ("Merge branch 'android11-5.4'
into 'android11-5.4-lts'").
As the main android11-5.4 branch had added new symbols to be tracked, we
need to properly track them here as well to ensure there is no abi
breakage over time with the LTS releases. So regenerate the .xml file
to properly handle them.
Leaf changes summary: 13 artifacts changed
Changed leaf types summary: 0 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 13 Added functions
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
13 Added functions:
[A] 'function int clk_notifier_unregister(clk*, notifier_block*)'
[A] 'function int drm_atomic_set_crtc_for_plane(drm_plane_state*, drm_crtc*)'
[A] 'function void drm_atomic_set_fb_for_plane(drm_plane_state*, drm_framebuffer*)'
[A] 'function void drm_connector_list_update(drm_connector*)'
[A] 'function int drm_dp_mst_atomic_check(drm_atomic_state*)'
[A] 'function void drm_dp_mst_dump_topology(seq_file*, drm_dp_mst_topology_mgr*)'
[A] 'function bool drm_is_current_master(drm_file*)'
[A] 'function drm_master* drm_master_get(drm_master*)'
[A] 'function void drm_master_put(drm_master**)'
[A] 'function void drm_mode_prune_invalid(drm_device*, list_head*, bool)'
[A] 'function void drm_mode_sort(list_head*)'
[A] 'function void drm_rect_rotate(drm_rect*, int, int, unsigned int)'
[A] 'function int idr_alloc_u32(idr*, void*, unsigned int*, unsigned long int, unsigned int)'
Fixes: 56f4fac695 ("Merge branch 'android11-5.4' into 'android11-5.4-lts'")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5f91a8798c94b7bc42b68929072070c2dbb00c97
Sync up with android11-5.4 for the following commits:
19c89b6bbf ANDROID: GKI: update KMI for db845c with idr_alloc_u32 added
9394e52285 Merge tag 'android11-5.4.86_r00' from 'android11-5.4-lts' into 'android11-5.4'
d3c11f4ae4 ANDROID: ABI: Update allowed list for QCOM
6b4f6cd53f ANDROID: ABI: update allowed list for QCOM
1d9c43fa3b ANDROID: ABI: Update allowed list for QCOM
f682b4505d ANDROID: build_config: drop CONFIG_KASAN_PANIC_ON_WARN
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3461f062469261b3074c4e46f04aea4023400aee
This merges the 5.4.86 upstream LTS release into the android11-5.4
branch so that all devices can get the needed important security and
other bugfixes that are in here. All devices must upgrade to remain
properly secure from known issues.
Bug: 180469075
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1041e0d08d55a3eb2e0f49b7d2384960f48d9b11
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmAs43QACgkQONu9yGCS
aT4omw/+JPBAZB5ClIOSDuf3/yJkbigVRFNVmQJy4/cluG32cxlcpudoau7AXq3N
0Sn/rfSdldl5eI98OTA+Y0yPIsVnQJdei228A5gmULkkc+rEFugorSJKRmmA7tH0
VdZ1C4NlhhmjoIT/W8mMNzv14dtyGQvRbT+zzfxqwqL6tF9+alcdBYTP/Z691K6x
8Csfe05MZ8VkvBizStaTXC+dtMhU917Ikd5i5v4ZzaesZJcUTLS7J82FhtKeoz7q
tDoA/Bl+pN1KjyIIE61/zJ8DKzBtOeuo1PWJFpO+EBVhKVosr3oWJfTAiM7Fsnu5
dbKHYPsbe3mB79JdQibr7TpU7vSjDr5a/HTuYtp7WM1R5IssiFeVOdpXTGim/s/E
Flao5LYSUcj0X/Io6TyUnxQWw8sJz3PGKYiLUn8/9DBpzNFzynQ+vuapXCoGxJzh
W108q32PIx2ZTJsD5RUUqZbytG/zKzI1+SxXo2uOhs9/k5qT+35Yp9epsE2Cp8v1
Oiw3P/ZUDNk6zPj0dsHcTsqTofRK07l71HnM8iIbCWSPw834IoGBuB8c3H7HaHn4
v5M4tMTDAaKi/e09K92fR6SZDgZz8D0N+sLLneA4NEASXIJanCUwcgVCUbja+BO1
H1hiYTTZQa7kOkSxBa/wGsWkdfvOpOvCSFr+c6LPmB9sHMe4K8o=
=3BI0
-----END PGP SIGNATURE-----
Merge 5.4.99 into android11-5.4-lts
Changes in 5.4.99
gpio: ep93xx: fix BUG_ON port F usage
gpio: ep93xx: Fix single irqchip with multi gpiochips
tracing: Do not count ftrace events in top level enable output
tracing: Check length before giving out the filter buffer
arm/xen: Don't probe xenbus as part of an early initcall
cgroup: fix psi monitor for root cgroup
arm64: dts: rockchip: Fix PCIe DT properties on rk3399
arm64: dts: qcom: sdm845: Reserve LPASS clocks in gcc
ARM: OMAP2+: Fix suspcious RCU usage splats for omap_enter_idle_coupled
platform/x86: hp-wmi: Disable tablet-mode reporting by default
ovl: perform vfs_getxattr() with mounter creds
cap: fix conversions on getxattr
ovl: skip getxattr of security labels
nvme-pci: ignore the subsysem NQN on Phison E16
drm/amd/display: Add more Clock Sources to DCN2.1
drm/amd/display: Fix dc_sink kref count in emulated_link_detect
drm/amd/display: Free atomic state after drm_atomic_commit
drm/amd/display: Decrement refcount of dc_sink before reassignment
riscv: virt_addr_valid must check the address belongs to linear mapping
bfq-iosched: Revert "bfq: Fix computation of shallow depth"
ARM: dts: lpc32xx: Revert set default clock rate of HCLK PLL
ARM: ensure the signal page contains defined contents
ARM: kexec: fix oops after TLB are invalidated
vmlinux.lds.h: Create section for protection against instrumentation
lkdtm: don't move ctors to .rodata
mt76: dma: fix a possible memory leak in mt76_add_fragment()
drm/vc4: hvs: Fix buffer overflow with the dlist handling
bpf: Check for integer overflow when using roundup_pow_of_two()
netfilter: xt_recent: Fix attempt to update deleted entry
netfilter: nftables: fix possible UAF over chains from packet path in netns
netfilter: flowtable: fix tcp and udp header checksum update
xen/netback: avoid race in xenvif_rx_ring_slots_available()
net: enetc: initialize the RFS and RSS memories
selftests: txtimestamp: fix compilation issue
net: stmmac: set TxQ mode back to DCB after disabling CBS
ibmvnic: Clear failover_pending if unable to schedule
netfilter: conntrack: skip identical origin tuple in same zone only
x86/build: Disable CET instrumentation in the kernel for 32-bit too
net: hns3: add a check for queue_id in hclge_reset_vf_queue()
firmware_loader: align .builtin_fw to 8
drm/sun4i: tcon: set sync polarity for tcon1 channel
drm/sun4i: Fix H6 HDMI PHY configuration
drm/sun4i: dw-hdmi: Fix max. frequency for H6
clk: sunxi-ng: mp: fix parent rate change flag check
i2c: stm32f7: fix configuration of the digital filter
h8300: fix PREEMPTION build, TI_PRE_COUNT undefined
usb: dwc3: ulpi: fix checkpatch warning
usb: dwc3: ulpi: Replace CPU-based busyloop with Protocol-based one
rxrpc: Fix clearance of Tx/Rx ring when releasing a call
udp: fix skb_copy_and_csum_datagram with odd segment sizes
net: dsa: call teardown method on probe failure
net: gro: do not keep too many GRO packets in napi->rx_list
net: fix iteration for sctp transport seq_files
net/vmw_vsock: improve locking in vsock_connect_timeout()
net: watchdog: hold device global xmit lock during tx disable
vsock/virtio: update credit only if socket is not closed
vsock: fix locking in vsock_shutdown()
net/rds: restrict iovecs length for RDS_CMSG_RDMA_ARGS
net/qrtr: restrict user-controlled length in qrtr_tun_write_iter()
ovl: expand warning in ovl_d_real()
Linux 5.4.99
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I28713d7ddd79d24b3007872877e51063df21a01e
commit cef4cbff06fbc3be54d6d79ee139edecc2ee8598 upstream.
There was a syzbot report with this warning but insufficient information...
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a11148e6fcce2ae53f47f0a442d098d860b4f7db upstream.
syzbot found WARNING in rds_rdma_extra_size [1] when RDS_CMSG_RDMA_ARGS
control message is passed with user-controlled
0x40001 bytes of args->nr_local, causing order >= MAX_ORDER condition.
The exact value 0x40001 can be checked with UIO_MAXIOV which is 0x400.
So for kcalloc() 0x400 iovecs with sizeof(struct rds_iovec) = 0x10
is the closest limit, with 0x10 leftover.
Same condition is currently done in rds_cmsg_rdma_args().
[1] WARNING: mm/page_alloc.c:5011
[..]
Call Trace:
alloc_pages_current+0x18c/0x2a0 mm/mempolicy.c:2267
alloc_pages include/linux/gfp.h:547 [inline]
kmalloc_order+0x2e/0xb0 mm/slab_common.c:837
kmalloc_order_trace+0x14/0x120 mm/slab_common.c:853
kmalloc_array include/linux/slab.h:592 [inline]
kcalloc include/linux/slab.h:621 [inline]
rds_rdma_extra_size+0xb2/0x3b0 net/rds/rdma.c:568
rds_rm_size net/rds/send.c:928 [inline]
Reported-by: syzbot+1bd2b07f93745fa38425@syzkaller.appspotmail.com
Signed-off-by: Sabyrzhan Tasbolatov <snovitoll@gmail.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Link: https://lore.kernel.org/r/20210201203233.1324704-1-snovitoll@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1c5fae9c9a092574398a17facc31c533791ef232 upstream.
In vsock_shutdown() we touched some socket fields without holding the
socket lock, such as 'state' and 'sk_flags'.
Also, after the introduction of multi-transport, we are accessing
'vsk->transport' in vsock_send_shutdown() without holding the lock
and this call can be made while the connection is in progress, so
the transport can change in the meantime.
To avoid issues, we hold the socket lock when we enter in
vsock_shutdown() and release it when we leave.
Among the transports that implement the 'shutdown' callback, only
hyperv_transport acquired the lock. Since the caller now holds it,
we no longer take it.
Fixes: d021c34405 ("VSOCK: Introduce VM Sockets")
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ce7536bc7398e2ae552d2fabb7e0e371a9f1fe46 upstream.
If the socket is closed or is being released, some resources used by
virtio_transport_space_update() such as 'vsk->trans' may be released.
To avoid a use after free bug we should only update the available credit
when we are sure the socket is still open and we have the lock held.
Fixes: 06a8fc7836 ("VSOCK: Introduce virtio_vsock_common.ko")
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Link: https://lore.kernel.org/r/20210208144454.84438-1-sgarzare@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3aa6bce9af0e25b735c9c1263739a5639a336ae8 upstream.
Prevent netif_tx_disable() running concurrently with dev_watchdog() by
taking the device global xmit lock. Otherwise, the recommended:
netif_carrier_off(dev);
netif_tx_disable(dev);
driver shutdown sequence can happen after the watchdog has already
checked carrier, resulting in possible false alarms. This is because
netif_tx_lock() only sets the frozen bit without maintaining the locks
on the individual queues.
Fixes: c3f26a269c ("netdev: Fix lockdep warnings in multiqueue configurations.")
Signed-off-by: Edwin Peer <edwin.peer@broadcom.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3d0bc44d39bca615b72637e340317b7899b7f911 upstream.
A possible locking issue in vsock_connect_timeout() was recognized by
Eric Dumazet which might cause a null pointer dereference in
vsock_transport_cancel_pkt(). This patch assures that
vsock_transport_cancel_pkt() will be called within the lock, so a race
condition won't occur which could result in vsk->transport to be set to NULL.
Fixes: 380feae0de ("vsock: cancel packets when failing to connect")
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Norbert Slusarek <nslusarek@gmx.net>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://lore.kernel.org/r/trinity-f8e0937a-cf0e-4d80-a76e-d9a958ba3ef1-1612535522360@3c-app-gmx-bap12
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit af8085f3a4712c57d0dd415ad543bac85780375c upstream.
The sctp transport seq_file iterators take a reference to the transport
in the ->start and ->next functions and releases the reference in the
->show function. The preferred handling for such resources is to
release them in the subsequent ->next or ->stop function call.
Since Commit 1f4aace60b ("fs/seq_file.c: simplify seq_file iteration
code and interface") there is no guarantee that ->show will be called
after ->next, so this function can now leak references.
So move the sctp_transport_put() call to ->next and ->stop.
Fixes: 1f4aace60b ("fs/seq_file.c: simplify seq_file iteration code and interface")
Reported-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8dc1c444df193701910f5e80b5d4caaf705a8fb0 upstream.
Commit c80794323e82 ("net: Fix packet reordering caused by GRO and
listified RX cooperation") had the unfortunate effect of adding
latencies in common workloads.
Before the patch, GRO packets were immediately passed to
upper stacks.
After the patch, we can accumulate quite a lot of GRO
packets (depdending on NAPI budget).
My fix is counting in napi->rx_count number of segments
instead of number of logical packets.
Fixes: c80794323e82 ("net: Fix packet reordering caused by GRO and listified RX cooperation")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Bisected-by: John Sperbeck <jsperbeck@google.com>
Tested-by: Jian Yang <jianyang@google.com>
Cc: Maxim Mikityanskiy <maximmi@mellanox.com>
Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Edward Cree <ecree.xilinx@gmail.com>
Reviewed-by: Alexander Lobakin <alobakin@pm.me>
Link: https://lore.kernel.org/r/20210204213146.4192368-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8fd54a73b7cda11548154451bdb4bde6d8ff74c7 upstream.
Since teardown is supposed to undo the effects of the setup method, it
should be called in the error path for dsa_switch_setup, not just in
dsa_switch_teardown.
Fixes: 5e3f847a02 ("net: dsa: Add teardown callback for drivers")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20210204163351.2929670-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 52cbd23a119c6ebf40a527e53f3402d2ea38eccb upstream.
When iteratively computing a checksum with csum_block_add, track the
offset "pos" to correctly rotate in csum_block_add when offset is odd.
The open coded implementation of skb_copy_and_csum_datagram did this.
With the switch to __skb_datagram_iter calling csum_and_copy_to_iter,
pos was reinitialized to 0 on each call.
Bring back the pos by passing it along with the csum to the callback.
Changes v1->v2
- pass csum value, instead of csump pointer (Alexander Duyck)
Link: https://lore.kernel.org/netdev/20210128152353.GB27281@optiplex/
Fixes: 950fcaecd5 ("datagram: consolidate datagram copy to iter helpers")
Reported-by: Oliver Graute <oliver.graute@gmail.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20210203192952.1849843-1-willemdebruijn.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7b5eab57cac45e270a0ad624ba157c5b30b3d44d upstream.
At the end of rxrpc_release_call(), rxrpc_cleanup_ring() is called to clear
the Rx/Tx skbuff ring, but this doesn't lock the ring whilst it's accessing
it. Unfortunately, rxrpc_resend() might be trying to retransmit a packet
concurrently with this - and whilst it does lock the ring, this isn't
protection against rxrpc_cleanup_call().
Fix this by removing the call to rxrpc_cleanup_ring() from
rxrpc_release_call(). rxrpc_cleanup_ring() will be called again anyway
from rxrpc_cleanup_call(). The earlier call is just an optimisation to
recycle skbuffs more quickly.
Alternative solutions include rxrpc_release_call() could try to cancel the
work item or wait for it to complete or rxrpc_cleanup_ring() could lock
when accessing the ring (which would require a bh lock).
This can produce a report like the following:
BUG: KASAN: use-after-free in rxrpc_send_data_packet+0x19b4/0x1e70 net/rxrpc/output.c:372
Read of size 4 at addr ffff888011606e04 by task kworker/0:0/5
...
Workqueue: krxrpcd rxrpc_process_call
Call Trace:
...
kasan_report.cold+0x79/0xd5 mm/kasan/report.c:413
rxrpc_send_data_packet+0x19b4/0x1e70 net/rxrpc/output.c:372
rxrpc_resend net/rxrpc/call_event.c:266 [inline]
rxrpc_process_call+0x1634/0x1f60 net/rxrpc/call_event.c:412
process_one_work+0x98d/0x15f0 kernel/workqueue.c:2275
...
Allocated by task 2318:
...
sock_alloc_send_pskb+0x793/0x920 net/core/sock.c:2348
rxrpc_send_data+0xb51/0x2bf0 net/rxrpc/sendmsg.c:358
rxrpc_do_sendmsg+0xc03/0x1350 net/rxrpc/sendmsg.c:744
rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:560
...
Freed by task 2318:
...
kfree_skb+0x140/0x3f0 net/core/skbuff.c:704
rxrpc_free_skb+0x11d/0x150 net/rxrpc/skbuff.c:78
rxrpc_cleanup_ring net/rxrpc/call_object.c:485 [inline]
rxrpc_release_call+0x5dd/0x860 net/rxrpc/call_object.c:552
rxrpc_release_calls_on_socket+0x21c/0x300 net/rxrpc/call_object.c:579
rxrpc_release_sock net/rxrpc/af_rxrpc.c:885 [inline]
rxrpc_release+0x263/0x5a0 net/rxrpc/af_rxrpc.c:916
__sock_release+0xcd/0x280 net/socket.c:597
...
The buggy address belongs to the object at ffff888011606dc0
which belongs to the cache skbuff_head_cache of size 232
Fixes: 248f219cb8 ("rxrpc: Rewrite the data and ack handling code")
Reported-by: syzbot+174de899852504e4a74a@syzkaller.appspotmail.com
Reported-by: syzbot+3d1c772efafd3c38d007@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Hillf Danton <hdanton@sina.com>
Link: https://lore.kernel.org/r/161234207610.653119.5287360098400436976.stgit@warthog.procyon.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fca3f138105727c3a22edda32d02f91ce1bf11c9 upstream
Originally the procedure of the ULPI transaction finish detection has been
developed as a simple busy-loop with just decrementing counter and no
delays. It's wrong since on different systems the loop will take a
different time to complete. So if the system bus and CPU are fast enough
to overtake the ULPI bus and the companion PHY reaction, then we'll get to
take a false timeout error. Fix this by converting the busy-loop procedure
to take the standard bus speed, address value and the registers access
mode into account for the busy-loop delay calculation.
Here is the way the fix works. It's known that the ULPI bus is clocked
with 60MHz signal. In accordance with [1] the ULPI bus protocol is created
so to spend 5 and 6 clock periods for immediate register write and read
operations respectively, and 6 and 7 clock periods - for the extended
register writes and reads. Based on that we can easily pre-calculate the
time which will be needed for the controller to perform a requested IO
operation. Note we'll still preserve the attempts counter in case if the
DWC USB3 controller has got some internals delays.
[1] UTMI+ Low Pin Interface (ULPI) Specification, Revision 1.1,
October 20, 2004, pp. 30 - 36.
Fixes: 88bc9d194f ("usb: dwc3: add ULPI interface support")
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201210085008.13264-3-Sergey.Semin@baikalelectronics.ru
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
