usb: gadget: Fix use-after-free bug by not setting udc->dev.driver
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: Fix use-after-free bug by not setting udc->dev.driver
The syzbot fuzzer found a use-after-free bug:
BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320
Read of size 8 at addr ffff88802b934098 by task udevd/3689
CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0x8d/0x303
In the Linux kernel, the following vulnerability has been resolved:
Input: aiptek - properly check endpoint type
Syzbot reported warning in usb_submit_urb() which is caused by wrong
endpoint type. There was a check for the number of endpoints, but not
for the type of endpoint.
Fix it by replacing old desc.bNumEndpoints check with
usb_find_common_endpoints() helper for finding endpoints
Fail log:
usb 5-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
Modules linked in:
CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07e
usb: usbtmc: Fix bug in pipe direction for control transfers
In the Linux kernel, the following vulnerability has been resolved:
usb: usbtmc: Fix bug in pipe direction for control transfers
The syzbot fuzzer reported a minor bug in the usbtmc driver:
usb 5-1: BOGUS control dir, pipe 80001e80 doesn't match bRequestType 0
WARNING: CPU: 0 PID: 3813 at drivers/usb/core/urb.c:412
usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410
Modules linked in:
CPU: 0 PID: 3813 Comm: syz-executor122 Not tainted
5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0
...
Call Trace:
<TASK>
usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58
usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
usb_con
btrfs: skip reserved bytes warning on unmount after log cleanup failure
In the Linux kernel, the following vulnerability has been resolved:
btrfs: skip reserved bytes warning on unmount after log cleanup failure
After the recent changes made by commit c2e39305299f01 ("btrfs: clear
extent buffer uptodate when we fail to write it") and its followup fix,
commit 651740a5024117 ("btrfs: check WRITE_ERR when trying to read an
extent buffer"), we can now end up not cleaning up space reservations of
log tree extent buffers after a transaction abort happens, as well as not
cleaning up still dirty extent buffers.
This happens because if writeback for a log tree extent buffer failed,
then we have cleared the bit EXTENT_B
In the Linux kernel, the following vulnerability has been resolved:
ima: fix reference leak in asymmetric_verify()
Don't leak a reference to the key if its algorithm is unknown.
can: isotp: fix potential CAN frame reception race in isotp_rcv()
In the Linux kernel, the following vulnerability has been resolved:
can: isotp: fix potential CAN frame reception race in isotp_rcv()
When receiving a CAN frame the current code logic does not consider
concurrently receiving processes which do not show up in real world
usage.
Ziyang Xuan writes:
The following syz problem is one of the scenarios. so->rx.len is
changed by isotp_rcv_ff() during isotp_rcv_cf(), so->rx.len equals
0 before alloc_skb() and equals 4096 after alloc_skb(). That will
trigger skb_over_panic() in skb_put().
=======================================================
CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc8
NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes
iattr::ia_size is a loff_t, so these NFSv3 procedures must be
careful to deal with incoming client size values that are larger
than s64_max without corrupting the value.
Silently capping the value results in storing a different value
than the client passed in which is unexpected behavior, so remove
the min_t() check in decode_sattr3().
Note that RFC 1813 permits only the WRITE procedure to return
NFS3ERR_FBIG. We believe that NFSv3 reference implementations
also return NFS3ERR_FBIG when ia_size is too large.
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix ia_size underflow
iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and
NFSv4 both define file size as an unsigned 64-bit type. Thus there
is a range of valid file size values an NFS client can send that is
already larger than Linux can handle.
Currently decode_fattr4() dumps a full u64 value into ia_size. If
that value happens to be larger than S64_MAX, then ia_size
underflows. I'm about to fix up the NFSv3 behavior as well, so let's
catch the underflow in the common code path: nfsd_setattr().
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix the behavior of READ near OFFSET_MAX
Dan Aloni reports:
> Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to
> the RPC read layers") on the client, a read of 0xfff is aligned up
> to server rsize of 0x1000.
>
> As a result, in a test where the server has a file of size
> 0x7fffffffffffffff, and the client tries to read from the offset
> 0x7ffffffffffff000, the read causes loff_t overflow in the server
> and it returns an NFS code of EINVAL to the client. The client as
> a result indefinitely retries the request.
The Linux NFS client does not hand
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: Fix deadlock on DSI device attach error
DSI device attach to DSI host will be done with host device's lock
held.
Un-registering host in "device attach" error path (ex: probe retry)
will result in deadlock with below call trace and non operational
DSI display.
Startup Call trace:
[ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8
[ 35.043048] mutex_lock_nested+0x7c/0xc8
[ 35.043060] device_del+0x4c/0x3e8
[ 35.043075] device_unregister+0x20/0x40
[ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28
[ 35.043093] device_for_each_child+0x68/0xb0
[
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedf: Add stag_work to all the vports
Call trace seen when creating NPIV ports, only 32 out of 64 show online.
stag work was not initialized for vport, hence initialize the stag work.
WARNING: CPU: 8 PID: 645 at kernel/workqueue.c:1635 __queue_delayed_work+0x68/0x80
CPU: 8 PID: 645 Comm: kworker/8:1 Kdump: loaded Tainted: G IOE --------- --
4.18.0-348.el8.x86_64 #1
Hardware name: Dell Inc. PowerEdge MX740c/0177V9, BIOS 2.12.2 07/09/2021
Workqueue: events fc_lport_timeout [libfc]
RIP: 0010:__queue_delayed_work+0x68/0x80
Code: 89 b2 88 00 00 00 44 89 82 90 00 00 00
In the Linux kernel, the following vulnerability has been resolved:
scsi: myrs: Fix crash in error case
In myrs_detect(), cs->disable_intr is NULL when privdata->hw_init() fails
with non-zero. In this case, myrs_cleanup(cs) will call a NULL ptr and
crash the kernel.
[ 1.105606] myrs 0000:00:03.0: Unknown Initialization Error 5A
[ 1.105872] myrs 0000:00:03.0: Failed to initialize Controller
[ 1.106082] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 1.110774] Call Trace:
[ 1.110950] myrs_cleanup+0xe4/0x150 [myrs]
[ 1.111135] myrs_probe.cold+0x91/0x56a [myrs]
[ 1.111302] ? DAC960_GEM_intr_handler+0x1
scsi: qedf: Fix refcount issue when LOGO is received during TMF
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedf: Fix refcount issue when LOGO is received during TMF
Hung task call trace was seen during LOGO processing.
[ 974.309060] [0000:00:00.0]:[qedf_eh_device_reset:868]: 1:0:2:0: LUN RESET Issued...
[ 974.309065] [0000:00:00.0]:[qedf_initiate_tmf:2422]: tm_flags 0x10 sc_cmd 00000000c16b930f op = 0x2a target_id = 0x2 lun=0
[ 974.309178] [0000:00:00.0]:[qedf_initiate_tmf:2431]: portid=016900 tm_flags =LUN RESET
[ 974.309222] [0000:00:00.0]:[qedf_initiate_tmf:2438]: orig io_req = 00000000ec78df8f xid = 0x180 ref_cnt = 1.
[ 974.309625] host1: rport 016900: Received L
In the Linux kernel, the following vulnerability has been resolved:
usb: f_fs: Fix use-after-free for epfile
Consider a case where ffs_func_eps_disable is called from
ffs_func_disable as part of composition switch and at the
same time ffs_epfile_release get called from userspace.
ffs_epfile_release will free up the read buffer and call
ffs_data_closed which in turn destroys ffs->epfiles and
mark it as NULL. While this was happening the driver has
already initialized the local epfile in ffs_func_eps_disable
which is now freed and waiting to acquire the spinlock. Once
spinlock is acquired the driver proceeds with the stale value
of epfile and
misc: fastrpc: avoid double fput() on failed usercopy
In the Linux kernel, the following vulnerability has been resolved:
misc: fastrpc: avoid double fput() on failed usercopy
If the copy back to userland fails for the FASTRPC_IOCTL_ALLOC_DMA_BUFF
ioctl(), we shouldn't assume that 'buf->dmabuf' is still valid. In fact,
dma_buf_fd() called fd_install() before, i.e. "consumed" one reference,
leaving us with none.
Calling dma_buf_put() will therefore put a reference we no longer own,
leading to a valid file descritor table entry for an already released
'file' object which is a straight use-after-free.
Simply avoid calling dma_buf_put() and rely on the process exit code to
do the necessary clean
phy: stm32: fix a refcount leak in stm32_usbphyc_pll_enable()
In the Linux kernel, the following vulnerability has been resolved:
phy: stm32: fix a refcount leak in stm32_usbphyc_pll_enable()
This error path needs to decrement "usbphyc->n_pll_cons.counter" before
returning.
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: mv88e6xxx: don't use devres for mdiobus
As explained in commits:
74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")
5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")
mdiobus_free() will panic when called from devm_mdiobus_free() <-
devres_release_all() <- __device_release_driver(), and that mdiobus was
not previously unregistered.
The mv88e6xxx is an MDIO device, so the initial set of constraints that
I thought would cause this (I2C or SPI buses which call ->remove on
->shutdown) do not apply. But there is one more whic
net: dsa: ar9331: register the mdiobus under devres
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: ar9331: register the mdiobus under devres
As explained in commits:
74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")
5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")
mdiobus_free() will panic when called from devm_mdiobus_free() <-
devres_release_all() <- __device_release_driver(), and that mdiobus was
not previously unregistered.
The ar9331 is an MDIO device, so the initial set of constraints that I
thought would cause this (I2C or SPI buses which call ->remove on
->shutdown) do not apply. But there is one more which
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: bcm_sf2: don't use devres for mdiobus
As explained in commits:
74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")
5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")
mdiobus_free() will panic when called from devm_mdiobus_free() <-
devres_release_all() <- __device_release_driver(), and that mdiobus was
not previously unregistered.
The Starfighter 2 is a platform device, so the initial set of
constraints that I thought would cause this (I2C or SPI buses which call
->remove on ->shutdown) do not apply. But there is one more