Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

jackpot51
Copy link
Member

@jackpot51 jackpot51 commented Mar 21, 2022

Draft until the following can be verified:

jgross1 and others added 30 commits March 7, 2022 09:48
Letting xenbus_grant_ring() tear down grants in the error case is
problematic, as the other side could already have used these grants.
Calling gnttab_end_foreign_access_ref() without checking success is
resulting in an unclear situation for any caller of xenbus_grant_ring()
as in the error case the memory pages of the ring page might be
partially mapped. Freeing them would risk unwanted foreign access to
them, while not freeing them would leak memory.

In order to remove the need to undo any gnttab_grant_foreign_access()
calls, use gnttab_alloc_grant_references() to make sure no further
error can occur in the loop granting access to the ring pages.

It should be noted that this way of handling removes leaking of
grant entries in the error case, too.

This is CVE-2022-23040 / part of XSA-396.

Reported-by: Demi Marie Obenour <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
Add a new grant table function gnttab_try_end_foreign_access(), which
will remove and free a grant if it is not in use.

Its main use case is to either free a grant if it is no longer in use,
or to take some other action if it is still in use. This other action
can be an error exit, or (e.g. in the case of blkfront persistent grant
feature) some special handling.

This is CVE-2022-23036, CVE-2022-23038 / part of XSA-396.

Reported-by: Demi Marie Obenour <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
---
V2:
- new patch
V4:
- add comments to header (Jan Beulich)
It isn't enough to check whether a grant is still being in use by
calling gnttab_query_foreign_access(), as a mapping could be realized
by the other side just after having called that function.

In case the call was done in preparation of revoking a grant it is
better to do so via gnttab_end_foreign_access_ref() and check the
success of that operation instead.

For the ring allocation use alloc_pages_exact() in order to avoid
high order pages in case of a multi-page ring.

If a grant wasn't unmapped by the backend without persistent grants
being used, set the device state to "error".

This is CVE-2022-23036 / part of XSA-396.

Reported-by: Demi Marie Obenour <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Roger Pau Monné <[email protected]>
---
V2:
- use gnttab_try_end_foreign_access()
V4:
- use alloc_pages_exact() and free_pages_exact()
- set state to error if backend didn't unmap (Roger Pau Monné)
It isn't enough to check whether a grant is still being in use by
calling gnttab_query_foreign_access(), as a mapping could be realized
by the other side just after having called that function.

In case the call was done in preparation of revoking a grant it is
better to do so via gnttab_end_foreign_access_ref() and check the
success of that operation instead.

This is CVE-2022-23037 / part of XSA-396.

Reported-by: Demi Marie Obenour <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
---
V2:
- use gnttab_try_end_foreign_access()
V3:
- don't use gnttab_try_end_foreign_access()
It isn't enough to check whether a grant is still being in use by
calling gnttab_query_foreign_access(), as a mapping could be realized
by the other side just after having called that function.

In case the call was done in preparation of revoking a grant it is
better to do so via gnttab_try_end_foreign_access() and check the
success of that operation instead.

This is CVE-2022-23038 / part of XSA-396.

Reported-by: Demi Marie Obenour <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
---
V2:
- use gnttab_try_end_foreign_access()
Using gnttab_query_foreign_access() is unsafe, as it is racy by design.

The use case in the gntalloc driver is not needed at all. While at it
replace the call of gnttab_end_foreign_access_ref() with a call of
gnttab_end_foreign_access(), which is what is really wanted there. In
case the grant wasn't used due to an allocation failure, just free the
grant via gnttab_free_grant_reference().

This is CVE-2022-23039 / part of XSA-396.

Reported-by: Demi Marie Obenour <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
---
V3:
- fix __del_gref() (Jan Beulich)
Remove gnttab_query_foreign_access(), as it is unused and unsafe to
use.

All previous use cases assumed a grant would not be in use after
gnttab_query_foreign_access() returned 0. This information is useless
in best case, as it only refers to a situation in the past, which could
have changed already.

Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
The usage of gnttab_end_foreign_access() in xenhcd_gnttab_done() is
not safe against a malicious backend, as the backend could keep the
I/O page mapped and modify it even after the granted memory page is
being used for completely other purposes in the local system.

So replace that use case with gnttab_try_end_foreign_access() and
disable the PV host adapter in case the backend didn't stop using the
granted page.

In xenhcd_urb_request_done() immediately return in case of setting
the device state to "error" instead of looking into further backend
responses.

Reported-by: Demi Marie Obenour <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
---
V2:
- use gnttab_try_end_foreign_access()
Instead of __get_free_pages() and free_pages() use alloc_pages_exact()
and free_pages_exact(). This is in preparation of a change of
gnttab_end_foreign_access() which will prohibit use of high-order
pages.

By using the local variable "order" instead of ring->intf->ring_order
in the error path of xen_9pfs_front_alloc_dataring() another bug is
fixed, as the error path can be entered before ring->intf->ring_order
is being set.

By using alloc_pages_exact() the size in bytes is specified for the
allocation, which fixes another bug for the case of
order < (PAGE_SHIFT - XEN_PAGE_SHIFT).

This is part of CVE-2022-23041 / XSA-396.

Reported-by: Simon Gaiser <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
---
V4:
- new patch
Instead of __get_free_pages() and free_pages() use alloc_pages_exact()
and free_pages_exact(). This is in preparation of a change of
gnttab_end_foreign_access() which will prohibit use of high-order
pages.

This is part of CVE-2022-23041 / XSA-396.

Reported-by: Simon Gaiser <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
---
V4:
- new patch
gnttab_end_foreign_access() is used to free a grant reference and
optionally to free the associated page. In case the grant is still in
use by the other side processing is being deferred. This leads to a
problem in case no page to be freed is specified by the caller: the
caller doesn't know that the page is still mapped by the other side
and thus should not be used for other purposes.

The correct way to handle this situation is to take an additional
reference to the granted page in case handling is being deferred and
to drop that reference when the grant reference could be freed
finally.

This requires that there are no users of gnttab_end_foreign_access()
left directly repurposing the granted page after the call, as this
might result in clobbered data or information leaks via the not yet
freed grant reference.

This is part of CVE-2022-23041 / XSA-396.

Reported-by: Simon Gaiser <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
---
V4:
- expand comment in header
V5:
- get page ref in case of kmalloc() failure, too
When calling gnttab_end_foreign_access_ref() the returned value must
be tested and the reaction to that value should be appropriate.

In case of failure in xennet_get_responses() the reaction should not be
to crash the system, but to disable the network device.

The calls in setup_netfront() can be replaced by calls of
gnttab_end_foreign_access(). While at it avoid double free of ring
pages and grant references via xennet_disconnect_backend() in this case.

This is CVE-2022-23042 / part of XSA-396.

Reported-by: Demi Marie Obenour <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
---
V2:
- avoid double free
V3:
- remove pointless initializer (Jan Beulich)
Commit 76bfc7c ("mmc: core: adjust polling interval for CMD1"),
significantly decreased the polling period from ~10-12ms into just a couple
of us. The purpose was to decrease the total time spent in the busy polling
loop, but unfortunate it has lead to problems, that causes eMMC cards to
never gets out busy and thus fails to be initialized.

To fix the problem, but also to try to keep some of the new improved
behaviour, let's start by using a polling period of 1-2ms, which then
increases for each loop, according to common polling loop in
__mmc_poll_for_busy().

Reported-by: Jean Rene Dawin <[email protected]>
Reported-by: H. Nikolaus Schaller <[email protected]>
Cc: Huijin Park <[email protected]>
Fixes: 76bfc7c ("mmc: core: adjust polling interval for CMD1")
Signed-off-by: Ulf Hansson <[email protected]>
Tested-by: Jean Rene Dawin <[email protected]>
Tested-by: H. Nikolaus Schaller <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
The function dma_set_mask() in setup_hw() can fail, so its return value
should be checked.

Fixes: 1700fe1 ("Add mISDN HFC PCI driver")
Reported-by: TOTE Robot <[email protected]>
Signed-off-by: Jia-Ju Bai <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
…_hw_prepare()

The function dma_alloc_coherent() in qed_vf_hw_prepare() can fail, so
its return value should be checked.

Fixes: 1408cc1 ("qed: Introduce VFs")
Reported-by: TOTE Robot <[email protected]>
Signed-off-by: Jia-Ju Bai <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
The skb->len field is read after the packet is sent to the network
stack. In the meantime, skb can be freed. This patch fixes this bug.

Fixes: c3e6b2c ("net: lantiq_xrx200: add ingress SG DMA support")
Reported-by: Eric Dumazet <[email protected]>
Signed-off-by: Aleksander Jan Bajkowski <[email protected]>
Acked-by: Hauke Mehrtens <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
When the driver fails to register net device, it should free the DMA
region first, and then do other cleanup.

Signed-off-by: Zheyu Ma <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
The maximum message size that can be send is bigger than
the  maximum site that skb_page_frag_refill can allocate.
So it is possible to write beyond the allocated buffer.

Fix this by doing a fallback to COW in that case.

v2:

Avoid get get_order() costs as suggested by Linus Torvalds.

Fixes: cac2661 ("esp4: Avoid skb_cow_data whenever possible")
Fixes: 03e2a30 ("esp6: Avoid skb_cow_data whenever possible")
Reported-by: valis <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
The xfrm{4,6}_beet_gso_segment() functions did not correctly set the
SKB_GSO_IPXIP4 and SKB_GSO_IPXIP6 gso types for the address family
tunneling case. Fix this by setting these gso types.

Fixes: 384a46e ("esp4: add gso_segment for esp4 beet mode")
Fixes: 7f9e40e ("esp6: add gso_segment for esp6 beet mode")
Signed-off-by: Steffen Klassert <[email protected]>
The esp tunnel GSO handlers use skb_mac_gso_segment to
push the inner packet to the segmentation handlers.
However, skb_mac_gso_segment takes the Ethernet Protocol
ID from 'skb->protocol' which is wrong for inter address
family tunnels. We fix this by introducing a new
skb_eth_gso_segment function.

This function can be used if it is necessary to pass the
Ethernet Protocol ID directly to the segmentation handler.
First users of this function will be the esp4 and esp6
tunnel segmentation handlers.

Fixes: c35fe41 ("xfrm: Add mode handlers for IPsec on layer 2")
Signed-off-by: Steffen Klassert <[email protected]>
Clang static analysis reports this issue
qed_sriov.c:4727:19: warning: Assigned value is
  garbage or undefined
  ivi->max_tx_rate = tx_rate ? tx_rate : link.speed;
                   ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

link is only sometimes set by the call to qed_iov_get_link()
qed_iov_get_link fails without setting link or returning
status.  So change the decl to return status.

Fixes: 73390ac ("qed*: support ndo_get_vf_config")
Signed-off-by: Tom Rix <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
According to Documentation/driver-api/usb/URB.rst when a device
is unplugged usb_submit_urb() returns -ENODEV.

This error code propagates all the way up to usbnet_read_cmd() and
usbnet_write_cmd() calls inside the smsc95xx.c driver during
Ethernet cable unplug, unbind or reboot.

This causes the following errors to be shown on reboot, for example:

ci_hdrc ci_hdrc.1: remove, state 1
usb usb2: USB disconnect, device number 1
usb 2-1: USB disconnect, device number 2
usb 2-1.1: USB disconnect, device number 3
smsc95xx 2-1.1:1.0 eth1: unregister 'smsc95xx' usb-ci_hdrc.1-1.1, smsc95xx USB 2.0 Ethernet
smsc95xx 2-1.1:1.0 eth1: Failed to read reg index 0x00000114: -19
smsc95xx 2-1.1:1.0 eth1: Error reading MII_ACCESS
smsc95xx 2-1.1:1.0 eth1: __smsc95xx_mdio_read: MII is busy
smsc95xx 2-1.1:1.0 eth1: Failed to read reg index 0x00000114: -19
smsc95xx 2-1.1:1.0 eth1: Error reading MII_ACCESS
smsc95xx 2-1.1:1.0 eth1: __smsc95xx_mdio_read: MII is busy
smsc95xx 2-1.1:1.0 eth1: hardware isn't capable of remote wakeup
usb 2-1.4: USB disconnect, device number 4
ci_hdrc ci_hdrc.1: USB bus 2 deregistered
ci_hdrc ci_hdrc.0: remove, state 4
usb usb1: USB disconnect, device number 1
ci_hdrc ci_hdrc.0: USB bus 1 deregistered
imx2-wdt 30280000.watchdog: Device shutdown: Expect reboot!
reboot: Restarting system

Ignore the -ENODEV errors inside __smsc95xx_mdio_read() and
__smsc95xx_phy_wait_not_busy() and do not print error messages
when -ENODEV is returned.

Fixes: a049a30 ("net: usb: Correct PHY handling of smsc95xx")
Signed-off-by: Fabio Estevam <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Add the number of interrupts per bank for Tegra241 (Grace) to
fix the probe failure.

Fixes: d1056b7 ("gpio: tegra186: Add support for Tegra241")
Signed-off-by: Akhil R <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Some GPIO lines have stopped working after the patch
commit 2ab73c6 ("gpio: Support GPIO controllers without pin-ranges")

And this has supposedly been fixed in the following patches
commit 89ad556 ("gpio: Avoid using pin ranges with !PINCTRL")
commit 6dbbf84 ("gpiolib: Don't free if pin ranges are not defined")

But an erratic behavior where some GPIO lines work while others do not work
has been introduced.

This patch reverts those changes so that the sysfs-gpio interface works
properly again.

Signed-off-by: Marcelo Roberto Jimenez <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
It appears that GPIO ACPI library uses ACPI debounce values directly.
However, the GPIO library APIs expect the debounce timeout to be in
microseconds.

Convert ACPI value of debounce to microseconds.

While at it, document this detail where it is appropriate.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215664
Reported-by: Kai-Heng Feng <[email protected]>
Fixes: 8dcb7a1 ("gpiolib: acpi: Take into account debounce settings")
Signed-off-by: Andy Shevchenko <[email protected]>
Tested-by: Kai-Heng Feng <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Currently we are observing occasional screen flickering when
PSR2 selective fetch is enabled. More specifically glitch seems
to happen on full frame update when cursor moves to coords
x = -1 or y = -1.

According to Bspec SF Single full frame should not be set if
SF Partial Frame Enable is not set. This happened to be true for
ADLP as PSR2_MAN_TRK_CTL_ENABLE is always set and for ADL_P it's
actually "SF Partial Frame Enable" (Bit 31).

Setting "SF Partial Frame Enable" bit also on full update seems to
fix screen flickering.

Also make code more clear by setting PSR2_MAN_TRK_CTL_ENABLE
only if not on ADL_P. Bit 31 has different meaning in ADL_P.

Bspec: 49274

v2: Fix Mihai Harpau email address
v3: Modify commit message and remove unnecessary comment

Tested-by: Lyude Paul <[email protected]>
Fixes: 7f6002e ("drm/i915/display: Enable PSR2 selective fetch by default")
Reported-by: Lyude Paul <[email protected]>
Cc: Mihai Harpau <[email protected]>
Cc: José Roberto de Souza <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/5077
Signed-off-by: Jouni Högander <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 8d5516d)
Signed-off-by: Tvrtko Ursulin <[email protected]>
In FOPEN_DIRECT_IO mode, fuse_file_write_iter() calls
fuse_direct_write_iter(), which normally calls fuse_direct_io(), which then
imports the write buffer with fuse_get_user_pages(), which uses
iov_iter_get_pages() to grab references to userspace pages instead of
actually copying memory.

On the filesystem device side, these pages can then either be read to
userspace (via fuse_dev_read()), or splice()d over into a pipe using
fuse_dev_splice_read() as pipe buffers with &nosteal_pipe_buf_ops.

This is wrong because after fuse_dev_do_read() unlocks the FUSE request,
the userspace filesystem can mark the request as completed, causing write()
to return. At that point, the userspace filesystem should no longer have
access to the pipe buffer.

Fix by copying pages coming from the user address space to new pipe
buffers.

Reported-by: Jann Horn <[email protected]>
Fixes: c302162 ("fuse: support splice() reading from fuse device")
Cc: <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
… error

The root of the problem is that we are selecting symbols that have
dependencies. This can cause random configurations that can fail.
The cleanest solution is to avoid using select.

This driver uses interfaces from the OMAP_GPMC driver so we have to
depend on it instead.

Fixes: 4cd335d ("mtd: rawnand: omap2: Prevent invalid configuration and build error")
Signed-off-by: Roger Quadros <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
…tigation reporting

The mitigations for Spectre-BHB are only applied when an exception is
taken from user-space. The mitigation status is reported via the spectre_v2
sysfs vulnerabilities file.

When unprivileged eBPF is enabled the mitigation in the exception vectors
can be avoided by an eBPF program.

When unprivileged eBPF is enabled, print a warning and report vulnerable
via the sysfs vulnerabilities file.

Acked-by: Catalin Marinas <[email protected]>
Signed-off-by: James Morse <[email protected]>
Similarly to what was earlier done for other Nyan variants, move the eDP
panel on the FHD models to the AUX bus as well.

Suggested-by: Dmitry Osipenko <[email protected]>
Fixes: ef6fb98 ("ARM: tegra: Add device-tree for 1080p version of Nyan Big")
Signed-off-by: Thierry Reding <[email protected]>
@jackpot51 jackpot51 requested review from a team March 21, 2022 13:40
@jackpot51 jackpot51 self-assigned this Mar 21, 2022
@XV-02
Copy link

XV-02 commented Mar 22, 2022

What are you looking for verification regarding 470 & 510?

@jackpot51
Copy link
Member Author

@XV-02 I mostly want to know that the DKMS modules compile.

@XV-02
Copy link

XV-02 commented Mar 22, 2022

With the 5.17 kernel, a fully updated and upgraded Pop 21.10 appears to be defaulting to Integrated graphics on Kudu6. While both the CLI and GUI system76-power graphics switch seems to act as expected - the GUI brings up the splash notifying the graphics switch and then resolves the restart now/later prompt, while the CLI seem to process the change and advise a reboot is required to effect the change - on reboot the system is still in Integrated graphics.

Currently, I'm testing purging the drivers and reinstalling.

@XV-02
Copy link

XV-02 commented Mar 23, 2022

The 470 driver will not install independently; dpkg reports nvidia-driver-470 claiming nvidia-dkms-470 as a dependency and vice-versa.

However, the 510 driver will install correctly, and system76-power correctly behaves with 510 running.

@jackpot51
Copy link
Member Author

Thanks, I will check it out.

@XV-02
Copy link

XV-02 commented Mar 23, 2022

The same issue with the 470 driver is present in Pop 20.04. Again, the 510 driver successfully installs and functions in concert with system76-power.

@jackpot51
Copy link
Member Author

@XV-02 can you provide the full output of sudo apt-get install nvidia-driver-470?

@XV-02
Copy link

XV-02 commented Mar 23, 2022

470InstallLog.txt

@jackpot51
Copy link
Member Author

Please grab the file /var/lib/dkms/nvidia/470.86/build/make.log

@XV-02
Copy link

XV-02 commented Mar 23, 2022

make.log

@XV-02
Copy link

XV-02 commented Mar 23, 2022

There are also some issues with Steam playing nice with the 5.17 Kernel. In dedicated Nvidia mode, Steam will not successfully launch from either the launcher or the terminal. Steam will launch in Hybrid and Integrated modes. When a game is launched in Hybrid mode, it will take advantage of the discrete GPU.

@XV-02
Copy link

XV-02 commented Mar 23, 2022

The issues with the 470 driver persists on desktop. Additionally, Steam generated "Fatal Error: Failed to load steamui.so" when trying to do a clean install on the 510 driver.

@jackpot51
Copy link
Member Author

Obsolete due to #130

@jackpot51 jackpot51 closed this Apr 4, 2022
@jackpot51 jackpot51 deleted the linux-5.17.0 branch April 4, 2022 13:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.