4.4.300-rc1 review
Subsystems (4)
Greg Kroah-Hartman
maintainercover 4.4.300-rc1 review
This is the start of the stable review cycle for the 4.4.300 release. There are 114 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Jan 2022 18:39:11 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.300-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.4.300-rc1
Miaoqian Lin <[email protected]>
lib82596: Fix IRQ check in sni_82596_probe
Sergey Shtylyov <[email protected]>
bcmgenet: add WOL IRQ check
Kevin Bracey <[email protected]>
net_sched: restore "mpu xxx" handling
Tudor Ambarus <[email protected]>
dmaengine: at_xdmac: Fix at_xdmac_lld struct definition
Tudor Ambarus <[email protected]>
dmaengine: at_xdmac: Fix lld view setting
Tudor Ambarus <[email protected]>
dmaengine: at_xdmac: Print debug message after realeasing the lock
Tudor Ambarus <[email protected]>
dmaengine: at_xdmac: Don't start transactions at tx_submit level
Eric Dumazet <[email protected]>
netns: add schedule point in ops_exit_list()
Robert Hancock <[email protected]>
net: axienet: fix number of TX ring slots for available check
Robert Hancock <[email protected]>
net: axienet: Wait for PhyRstCmplt after core reset
Eric Dumazet <[email protected]>
af_unix: annote lockless accesses to unix_tot_inflight & gc_in_progress
Miaoqian Lin <[email protected]>
parisc: pdc_stable: Fix memory leak in pdcs_register_pathentries
Tobias Waldekranz <[email protected]>
net/fsl: xgmac_mdio: Fix incorrect iounmap when removing module
Tobias Waldekranz <[email protected]>
powerpc/fsl/dts: Enable WA for erratum A-009885 on fman3l MDIO buses
Theodore Ts'o <[email protected]>
ext4: don't use the orphan list when migrating an inode
Ye Bin <[email protected]>
ext4: Fix BUG_ON in ext4_bread when write quota data
Luís Henriques <[email protected]>
ext4: set csum seed in tmp inode while migrating to extents
Petr Cvachoucek <[email protected]>
ubifs: Error path in ubifs_remount_rw() seems to wrongly free write buffers
Yauhen Kharuzhy <[email protected]>
power: bq25890: Enable continuous conversion for ADC at charging
Christoph Hellwig <[email protected]>
scsi: sr: Don't use GFP_DMA
Tianjia Zhang <[email protected]>
MIPS: Octeon: Fix build errors using clang
Lakshmi Sowjanya D <[email protected]>
i2c: designware-pci: Fix to change data types of hcnt and lcnt parameters
Takashi Iwai <[email protected]>
ALSA: seq: Set upper limit of processed events
Christophe Leroy <[email protected]>
w1: Misuse of get_user()/put_user() reported by sparse
Joakim Tjernlund <[email protected]>
i2c: mpc: Correct I2C reset procedure
Michael Ellerman <[email protected]>
powerpc/smp: Move setup_profiling_timer() under CONFIG_PROFILING
Heiner Kallweit <[email protected]>
i2c: i801: Don't silently correct invalid transfer size
Julia Lawall <[email protected]>
powerpc/btext: add missing of_node_put
Julia Lawall <[email protected]>
powerpc/cell: add missing of_node_put
Julia Lawall <[email protected]>
powerpc/powernv: add missing of_node_put
Julia Lawall <[email protected]>
powerpc/6xx: add missing of_node_put
John David Anglin <[email protected]>
parisc: Avoid calling faulthandler_disabled() twice
Lukas Wunner <[email protected]>
serial: core: Keep mctrl register state and cached copy in sync
Lukas Wunner <[email protected]>
serial: pl010: Drop CR register reset on set_termios
Joe Thornber <[email protected]>
dm space map common: add bounds check to sm_ll_lookup_bitmap()
Joe Thornber <[email protected]>
dm btree: add a defensive bounds check to insert_at()
Florian Fainelli <[email protected]>
net: mdio: Demote probed message to debug print
Josef Bacik <[email protected]>
btrfs: remove BUG_ON(!eie) in find_parent_nodes
Josef Bacik <[email protected]>
btrfs: remove BUG_ON() in find_parent_nodes()
Rafael J. Wysocki <[email protected]>
ACPICA: Executer: Fix the REFCLASS_REFOF case in acpi_ex_opcode_1A_0T_1R()
Rafael J. Wysocki <[email protected]>
ACPICA: Utilities: Avoid deleting the same object twice in a row
Randy Dunlap <[email protected]>
um: registers: Rename function names to avoid conflicts and build problems
Zekun Shen <[email protected]>
ath9k: Fix out-of-bound memcpy in ath9k_hif_usb_rx_stream
Kai-Heng Feng <[email protected]>
usb: hub: Add delay for SuperSpeed hub resume to let links transit to U0
Zhou Qingyang <[email protected]>
media: saa7146: hexium_gemini: Fix a NULL pointer dereference in hexium_attach()
Sean Young <[email protected]>
media: igorplugusb: receiver overflow should be reported
Suresh Kumar <[email protected]>
net: bonding: debug: avoid printing debug logs when bond is not notifying peers
Johannes Berg <[email protected]>
iwlwifi: mvm: synchronize with FW after multicast commands
Mauro Carvalho Chehab <[email protected]>
media: m920x: don't use stack on USB reads
Zhou Qingyang <[email protected]>
media: saa7146: hexium_orion: Fix a NULL pointer dereference in hexium_attach()
Xiongwei Song <[email protected]>
floppy: Add max size check for user space request
Zekun Shen <[email protected]>
mwifiex: Fix skb_over_panic in mwifiex_usb_recv()
Chengfeng Ye <[email protected]>
HSI: core: Fix return freed object in hsi_new_client
Zheyu Ma <[email protected]>
media: b2c2: Add missing check in flexcop_pci_isr:
Pavankumar Kondeti <[email protected]>
usb: gadget: f_fs: Use stream_open() for endpoint files
Zekun Shen <[email protected]>
ar5523: Fix null-ptr-deref with unexpected WDCMSG_TARGET_START reply
Alexander Aring <[email protected]>
fs: dlm: filter user dlm messages for kernel locks
Wei Yongjun <[email protected]>
Bluetooth: Fix debugfs entry leak in hci_register_dev()
Kamal Heib <[email protected]>
RDMA/cxgb4: Set queue pair state when being queried
Randy Dunlap <[email protected]>
mips: bcm63xx: add support for clk_set_parent()
Randy Dunlap <[email protected]>
mips: lantiq: add support for clk_set_parent()
Wei Yongjun <[email protected]>
misc: lattice-ecp3-config: Fix task hung when firmware load failed
Jiasheng Jiang <[email protected]>
ASoC: samsung: idma: Check of ioremap return value
Arnd Bergmann <[email protected]>
dmaengine: pxa/mmp: stop referencing config->slave_id
Avihai Horon <[email protected]>
RDMA/core: Let ib_find_gid() continue search even after empty entry
Jiasheng Jiang <[email protected]>
uio: uio_dmem_genirq: Catch the Exception
Kees Cook <[email protected]>
char/mwave: Adjust io port register size
Bixuan Cui <[email protected]>
ALSA: oss: fix compile error when OSS_DEBUG is enabled
Peiwei Hu <[email protected]>
powerpc/prom_init: Fix improper check of prom_getprop()
Takashi Iwai <[email protected]>
ALSA: hda: Add missing rwsem around snd_ctl_remove() calls
Takashi Iwai <[email protected]>
ALSA: PCM: Add missing rwsem around snd_ctl_remove() calls
Takashi Iwai <[email protected]>
ALSA: jack: Add missing rwsem around snd_ctl_remove() calls
Jan Kara <[email protected]>
ext4: avoid trim error on fs with small groups
Pavel Skripkin <[email protected]>
net: mcs7830: handle usb read errors properly
Dominik Brodowski <[email protected]>
pcmcia: fix setting of kthread task states
Jiasheng Jiang <[email protected]>
can: xilinx_can: xcan_probe(): check for error irq
Marc Kleine-Budde <[email protected]>
can: softing: softing_startstop(): fix set but not used variable warning
Miaoqian Lin <[email protected]>
spi: spi-meson-spifc: Add missing pm_runtime_disable() in meson_spifc_probe
Eric Dumazet <[email protected]>
ppp: ensure minimum packet size in ppp_write()
Zhou Qingyang <[email protected]>
pcmcia: rsrc_nonstatic: Fix a NULL pointer dereference in nonstatic_find_mem_region()
Zhou Qingyang <[email protected]>
pcmcia: rsrc_nonstatic: Fix a NULL pointer dereference in __nonstatic_find_io_region()
Wei Yongjun <[email protected]>
usb: ftdi-elan: fix memory leak on device disconnect
Wang Hai <[email protected]>
media: msi001: fix possible null-ptr-deref in msi001_probe()
Zhou Qingyang <[email protected]>
media: saa7146: mxb: Fix a NULL pointer dereference in mxb_attach()
Zhou Qingyang <[email protected]>
media: dib8000: Fix a memleak in dib8000_init()
Tasos Sahanidis <[email protected]>
floppy: Fix hang in watchdog when disk is ejected
Lino Sanfilippo <[email protected]>
serial: amba-pl011: do not request memory region twice
Zhou Qingyang <[email protected]>
drm/amdgpu: Fix a NULL pointer dereference in amdgpu_connector_lcd_native_mode()
Dmitry Baryshkov <[email protected]>
arm64: dts: qcom: msm8916: fix MMC controller aliases
Florian Westphal <[email protected]>
netfilter: bridge: add support for pppoe filtering
Tudor Ambarus <[email protected]>
tty: serial: atmel: Call dma_async_issue_pending()
Tudor Ambarus <[email protected]>
tty: serial: atmel: Check return code of dmaengine_submit()
Chengfeng Ye <[email protected]>
crypto: qce - fix uaf on qce_ahash_register_one
Pavel Skripkin <[email protected]>
Bluetooth: stop proccessing malicious adv data
Wang Hai <[email protected]>
Bluetooth: cmtp: fix possible panic when cmtp_init_sockets() fails
Yifeng Li <[email protected]>
PCI: Add function 1 DMA alias quirk for Marvell 88SE9125 SATA controller
Johan Hovold <[email protected]>
can: softing_cs: softingcs_probe(): fix memleak on registration failure
Johan Hovold <[email protected]>
media: stk1160: fix control-message timeouts
Johan Hovold <[email protected]>
media: pvrusb2: fix control-message timeouts
Michael Kuron <[email protected]>
media: dib0700: fix undefined behavior in tuner shutdown
Johan Hovold <[email protected]>
media: em28xx: fix control-message timeouts
Johan Hovold <[email protected]>
media: mceusb: fix control-message timeouts
Mateusz Jończyk <[email protected]>
rtc: cmos: take rtc_lock while reading from CMOS
Krzysztof Kozlowski <[email protected]>
nfc: llcp: fix NULL error pointer dereference on sendmsg() after failed bind()
Jann Horn <[email protected]>
HID: uhid: Fix worker destroying device without any protection
Larry Finger <[email protected]>
rtlwifi: rtl8192cu: Fix WARNING when calling local_irq_restore() with interrupts enabled
Johan Hovold <[email protected]>
media: uvcvideo: fix division by zero at stream start
Nathan Chancellor <[email protected]>
drm/i915: Avoid bitwise vs logical OR warning in snb_wm_latency_quirk()
Brian Silverman <[email protected]>
can: gs_usb: gs_can_start_xmit(): zero-initialize hf->{flags,reserved}Marc Kleine-Budde <[email protected]>
can: gs_usb: fix use of uninitialized variable, detach device on reception of invalid USB data
Andy Shevchenko <[email protected]>
mfd: intel-lpss: Fix too early PM enablement in the ACPI ->probe()
Alan Stern <[email protected]>
USB: Fix "slab-out-of-bounds Write" bug in usb_hcd_poll_rh_status
Alan Stern <[email protected]>
USB: core: Fix bug in resuming hub's handling of wakeup requests
Johan Hovold <[email protected]>
Bluetooth: bfusb: fix division by zero in send path
-------------
Diffstat:
Makefile | 4 +-- arch/arm64/boot/dts/qcom/msm8916.dtsi | 4 +-- arch/mips/bcm63xx/clk.c | 6 ++++ arch/mips/include/asm/octeon/cvmx-bootinfo.h | 4 +-- arch/mips/lantiq/clk.c | 6 ++++ arch/parisc/kernel/traps.c | 2 +- arch/powerpc/boot/dts/fsl/qoriq-fman3l-0.dtsi | 2 ++ arch/powerpc/kernel/btext.c | 4 ++- arch/powerpc/kernel/prom_init.c | 2 +- arch/powerpc/kernel/smp.c | 2 ++ arch/powerpc/platforms/cell/iommu.c | 1 + arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 1 + arch/powerpc/platforms/powernv/opal-lpc.c | 1 + arch/um/include/shared/registers.h | 4 +-- arch/um/os-Linux/registers.c | 4 +-- arch/um/os-Linux/start_up.c | 2 +- arch/x86/um/syscalls_64.c | 3 +- drivers/acpi/acpica/exoparg1.c | 3 +- drivers/acpi/acpica/utdelete.c | 1 + drivers/block/floppy.c | 6 ++-- drivers/bluetooth/bfusb.c | 3 ++ drivers/char/mwave/3780i.h | 2 +- drivers/crypto/qce/sha.c | 2 +- drivers/dma/at_xdmac.c | 32 ++++++++++------------ drivers/dma/mmp_pdma.c | 6 ---- drivers/dma/pxa_dma.c | 7 ----- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 6 ++++ drivers/gpu/drm/i915/intel_pm.c | 6 ++-- drivers/hid/uhid.c | 29 +++++++++++++++++--- drivers/hsi/hsi.c | 1 + drivers/i2c/busses/i2c-designware-pcidrv.c | 8 +++--- drivers/i2c/busses/i2c-i801.c | 15 ++++------ drivers/i2c/busses/i2c-mpc.c | 23 ++++++++++------ drivers/infiniband/core/device.c | 3 +- drivers/infiniband/hw/cxgb4/qp.c | 1 + drivers/md/persistent-data/dm-btree.c | 8 ++++-- drivers/md/persistent-data/dm-space-map-common.c | 5 ++++ drivers/media/common/saa7146/saa7146_fops.c | 2 +- drivers/media/dvb-frontends/dib8000.c | 4 ++- drivers/media/pci/b2c2/flexcop-pci.c | 3 ++ drivers/media/pci/saa7146/hexium_gemini.c | 7 ++++- drivers/media/pci/saa7146/hexium_orion.c | 8 +++++- drivers/media/pci/saa7146/mxb.c | 8 +++++- drivers/media/rc/igorplugusb.c | 4 ++- drivers/media/rc/mceusb.c | 8 +++--- drivers/media/tuners/msi001.c | 7 +++++ drivers/media/usb/dvb-usb/dib0700_core.c | 2 -- drivers/media/usb/dvb-usb/m920x.c | 12 +++++++- drivers/media/usb/em28xx/em28xx-core.c | 4 +-- drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 8 +++--- drivers/media/usb/stk1160/stk1160-core.c | 4 +-- drivers/media/usb/uvc/uvc_video.c | 4 +++ drivers/mfd/intel-lpss-acpi.c | 7 ++++- drivers/misc/lattice-ecp3-config.c | 12 ++++---- drivers/net/bonding/bond_main.c | 6 ++-- drivers/net/can/softing/softing_cs.c | 2 +- drivers/net/can/softing/softing_fw.c | 11 ++++---- drivers/net/can/usb/gs_usb.c | 5 +++- drivers/net/can/xilinx_can.c | 7 ++++- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 10 ++++--- drivers/net/ethernet/freescale/xgmac_mdio.c | 3 +- drivers/net/ethernet/i825xx/sni_82596.c | 3 +- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 14 ++++++++-- drivers/net/phy/mdio_bus.c | 2 +- drivers/net/ppp/ppp_generic.c | 7 ++++- drivers/net/usb/mcs7830.c | 12 ++++++-- drivers/net/wireless/ath/ar5523/ar5523.c | 4 +++ drivers/net/wireless/ath/ath9k/hif_usb.c | 7 +++++ drivers/net/wireless/iwlwifi/mvm/mac80211.c | 17 ++++++++++++ drivers/net/wireless/mwifiex/usb.c | 3 +- .../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 1 + drivers/parisc/pdc_stable.c | 4 ++- drivers/pci/quirks.c | 3 ++ drivers/pcmcia/cs.c | 8 ++---- drivers/pcmcia/rsrc_nonstatic.c | 6 ++++ drivers/power/bq25890_charger.c | 4 +-- drivers/rtc/rtc-cmos.c | 3 ++ drivers/scsi/sr.c | 2 +- drivers/scsi/sr_vendor.c | 4 +-- drivers/spi/spi-meson-spifc.c | 1 + drivers/tty/serial/amba-pl010.c | 3 -- drivers/tty/serial/amba-pl011.c | 27 ++---------------- drivers/tty/serial/atmel_serial.c | 14 ++++++++++ drivers/tty/serial/serial_core.c | 3 +- drivers/uio/uio_dmem_genirq.c | 6 +++- drivers/usb/core/hcd.c | 9 +++++- drivers/usb/core/hub.c | 7 +++-- drivers/usb/gadget/function/f_fs.c | 4 +-- drivers/usb/misc/ftdi-elan.c | 1 + drivers/w1/slaves/w1_ds28e04.c | 26 ++++-------------- fs/btrfs/backref.c | 21 +++++++++++--- fs/dlm/lock.c | 9 ++++++ fs/ext4/ioctl.c | 2 -- fs/ext4/mballoc.c | 8 ++++++ fs/ext4/migrate.c | 23 ++++++++-------- fs/ext4/super.c | 2 +- fs/ubifs/super.c | 1 - include/net/sch_generic.h | 5 ++++ net/bluetooth/cmtp/core.c | 4 +-- net/bluetooth/hci_core.c | 1 + net/bluetooth/hci_event.c | 8 +++++- net/bridge/br_netfilter_hooks.c | 7 ++--- net/core/net_namespace.c | 4 ++- net/nfc/llcp_sock.c | 5 ++++ net/sched/sch_generic.c | 1 + net/unix/garbage.c | 14 ++++++++-- net/unix/scm.c | 6 ++-- sound/core/jack.c | 3 ++ sound/core/oss/pcm_oss.c | 2 +- sound/core/pcm.c | 6 +++- sound/core/seq/seq_queue.c | 14 ++++++++-- sound/pci/hda/hda_codec.c | 3 ++ sound/soc/samsung/idma.c | 2 ++ 113 files changed, 485 insertions(+), 238 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/114 Bluetooth: bfusb: fix division by zero in send path
From: Johan Hovold <[email protected]>
commit b5e6fa7a12572c82f1e7f2f51fbb02a322291291 upstream.
Add the missing bulk-out endpoint sanity check to probe() to avoid division by zero in bfusb_send_frame() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing).
Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")).
--- drivers/bluetooth/bfusb.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/bluetooth/bfusb.c +3 -0
@@ -645,6 +645,9 @@ static int bfusb_probe(struct usb_interf data->bulk_out_ep = bulk_out_ep->desc.bEndpointAddress; data->bulk_pkt_size =le16_to_cpu (bulk_out_ep->desc.wMaxPacketSize); +if (!data->bulk_pkt_size) + goto done; +rwlock_init (&data->lock); data->reassembly =NULL ;
Greg Kroah-Hartman
maintainerPATCH 2/114 USB: core: Fix bug in resuming hubs handling of wakeup requests
In reply to Greg Kroah-HartmanFrom: Alan Stern <[email protected]>
commit 0f663729bb4afc92a9986b66131ebd5b8a9254d1 upstream.
Bugzilla #213839 reports a 7-port hub that doesn't work properly when devices are plugged into some of the ports; the kernel goes into an unending disconnect/reinitialize loop as shown in the bug report.
This "7-port hub" comprises two four-port hubs with one plugged into the other; the failures occur when a device is plugged into one of the downstream hub's ports. (These hubs have other problems too. For example, they bill themselves as USB-2.0 compliant but they only run at full speed.)
It turns out that the failures are caused by bugs in both the kernel and the hub. The hub's bug is that it reports a different bmAttributes value in its configuration descriptor following a remote wakeup (0xe0 before, 0xc0 after -- the wakeup-support bit has changed).
The kernel's bug is inside the hub driver's resume handler. When hub_activate() sees that one of the hub's downstream ports got a wakeup request from a child device, it notes this fact by setting the corresponding bit in the hub->change_bits variable. But this variable is meant for connection changes, not wakeup events; setting it causes the driver to believe the downstream port has been disconnected and then connected again (in addition to having received a wakeup request).
Because of this, the hub driver then tries to check whether the device currently plugged into the downstream port is the same as the device that had been attached there before. Normally this check succeeds and wakeup handling continues with no harm done (which is why the bug remained undetected until now). But with these dodgy hubs, the check fails because the config descriptor has changed. This causes the hub driver to reinitialize the child device, leading to the disconnect/reinitialize loop described in the bug report.
The proper way to note reception of a downstream wakeup request is to set a bit in the hub->event_bits variable instead of hub->change_bits. That way the hub driver will realize that something has happened to the port but will not think the port and child device have been disconnected. This patch makes that change.
--- drivers/usb/core/hub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/core/hub.c +1 -1
@@ -1169,7 +1169,7 @@ static void hub_activate(struct usb_hub*/ if (portchange || (hub_is_superspeed (hub->hdev) && port_resumed)) -set_bit (port1, hub->change_bits); +set_bit (port1, hub->event_bits); }else if (udev->persist_enabled) {#ifdef CONFIG_PM
Greg Kroah-Hartman
maintainerPATCH 3/114 USB: Fix "slab-out-of-bounds Write" bug in usb_hcd_poll_rh_status
In reply to Greg Kroah-HartmanFrom: Alan Stern <[email protected]>
commit 1d7d4c07932e04355d6e6528d44a2f2c9e354346 upstream.
When the USB core code for getting root-hub status reports was originally written, it was assumed that the hub driver would be its only caller. But this isn't true now; user programs can use usbfs to communicate with root hubs and get status reports. When they do this, they may use a transfer_buffer that is smaller than the data returned by the HCD, which will lead to a buffer overflow error when usb_hcd_poll_rh_status() tries to store the status data. This was discovered by syzbot:
BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline] BUG: KASAN: slab-out-of-bounds in usb_hcd_poll_rh_status+0x5f4/0x780 drivers/usb/core/hcd.c:776 Write of size 2 at addr ffff88801da403c0 by task syz-executor133/4062
This patch fixes the bug by reducing the amount of status data if it won't fit in the transfer_buffer. If some data gets discarded then the URB's completion status is set to -EOVERFLOW rather than 0, to let the user know what happened.
--- drivers/usb/core/hcd.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/usb/core/hcd.c +8 -1
@@ -731,6 +731,7 @@ void usb_hcd_poll_rh_status(struct usb_h {struct urb *urb;int length; +int status;unsigned long flags;char buffer[6 ];/* Any root hubs with > 31 ports? */
@@ -748,11 +749,17 @@ void usb_hcd_poll_rh_status(struct usb_hif (urb) {clear_bit (HCD_FLAG_POLL_PENDING , &hcd->flags); hcd->status_urb =NULL ; +if (urb->transfer_buffer_length >= length) { + status =0 ; + }else { + status = -EOVERFLOW ; + length = urb->transfer_buffer_length; + } urb->actual_length = length;memcpy (urb->transfer_buffer, buffer, length);usb_hcd_unlink_urb_from_ep (hcd, urb); -usb_hcd_giveback_urb (hcd, urb,0 ); +usb_hcd_giveback_urb (hcd, urb, status); }else { length =0 ;set_bit (HCD_FLAG_POLL_PENDING , &hcd->flags);
Greg Kroah-Hartman
maintainerPATCH 4/114 mfd: intel-lpss: Fix too early PM enablement in the ACPI ->probe()
In reply to Greg Kroah-HartmanFrom: Andy Shevchenko <[email protected]>
commit c9e143084d1a602f829115612e1ec79df3727c8b upstream.
The runtime PM callback may be called as soon as the runtime PM facility is enabled and activated. It means that ->suspend() may be called before we finish probing the device in the ACPI case. Hence, NULL pointer dereference:
intel-lpss INT34BA:00: IRQ index 0 not found
BUG: kernel NULL pointer dereference, address: 0000000000000030 ... Workqueue: pm pm_runtime_work RIP: 0010:intel_lpss_suspend+0xb/0x40 [intel_lpss]
To fix this, first try to register the device and only after that enable runtime PM facility.
--- drivers/mfd/intel-lpss-acpi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/mfd/intel-lpss-acpi.c +6 -1
@@ -53,6 +53,7 @@ static int intel_lpss_acpi_probe(struct {struct intel_lpss_platform_info *info;const struct acpi_device_id *id; +int ret; id =acpi_match_device (intel_lpss_acpi_ids, &pdev->dev);if (!id)
@@ -66,10 +67,14 @@ static int intel_lpss_acpi_probe(struct info->mem =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); info->irq =platform_get_irq (pdev,0 ); + ret =intel_lpss_probe (&pdev->dev, info); +if (ret) +return ret; +pm_runtime_set_active (&pdev->dev);pm_runtime_enable (&pdev->dev); -return intel_lpss_probe (&pdev->dev, info); +return 0 ; }static int intel_lpss_acpi_remove (struct platform_device *pdev)
Greg Kroah-Hartman
maintainerPATCH 5/114 can: gs_usb: fix use of uninitialized variable, detach device on reception of invalid USB data
In reply to Greg Kroah-HartmanFrom: Marc Kleine-Budde <[email protected]>
commit 4a8737ff068724f509d583fef404d349adba80d6 upstream.
The received data contains the channel the received data is associated with. If the channel number is bigger than the actual number of channels assume broken or malicious USB device and shut it down.
This fixes the error found by clang:
| drivers/net/can/usb/gs_usb.c:386:6: error: variable 'dev' is used | uninitialized whenever 'if' condition is true | if (hf->channel >= GS_MAX_INTF) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ | drivers/net/can/usb/gs_usb.c:474:10: note: uninitialized use occurs here | hf, dev->gs_hf_size, gs_usb_receive_bulk_callback, | ^~~
--- drivers/net/can/usb/gs_usb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/can/usb/gs_usb.c +2 -1
@@ -303,7 +303,7 @@ static void gs_usb_receive_bulk_callback/* device reports out of range channel id */ if (hf->channel >=GS_MAX_INTF ) - goto resubmit_urb; + goto device_detach; dev = usbcan->canch[hf->channel];
@@ -388,6 +388,7 @@ static void gs_usb_receive_bulk_callback/* USB failure take down all interfaces */ if (rc == -ENODEV ) { + device_detach:for (rc =0 ; rc <GS_MAX_INTF ; rc++) {if (usbcan->canch[rc])netif_device_detach (usbcan->canch[rc]->netdev);
Greg Kroah-Hartman
maintainerPATCH 6/114 can: gs_usb: gs_can_start_xmit(): zero-initialize hf->{flags,reserved}
In reply to Greg Kroah-HartmanFrom: Brian Silverman <[email protected]>
commit 89d58aebe14a365c25ba6645414afdbf4e41cea4 upstream.
No information is deliberately sent in hf->flags in host -> device communications, but the open-source candleLight firmware echoes it back, which can result in the GS_CAN_FLAG_OVERFLOW flag being set and generating spurious ERRORFRAMEs.
While there also initialize the reserved member with 0.
--- drivers/net/can/usb/gs_usb.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/can/usb/gs_usb.c +2 -0
@@ -491,6 +491,8 @@ static netdev_tx_t gs_can_start_xmit(str hf->echo_id = idx; hf->channel = dev->channel; + hf->flags =0 ; + hf->reserved =0 ; cf = (struct can_frame *)skb->data;
Greg Kroah-Hartman
maintainerPATCH 7/114 drm/i915: Avoid bitwise vs logical OR warning in snb_wm_latency_quirk()
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
commit 2e70570656adfe1c5d9a29940faa348d5f132199 upstream.
A new warning in clang points out a place in this file where a bitwise OR is being used with boolean types:
drivers/gpu/drm/i915/intel_pm.c:3066:12: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
changed = ilk_increase_wm_latency(dev_priv, dev_priv->wm.pri_latency, 12) |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~This construct is intentional, as it allows every one of the calls to ilk_increase_wm_latency() to occur (instead of short circuiting with logical OR) while still caring about the result of each call.
To make this clearer to the compiler, use the '|=' operator to assign the result of each ilk_increase_wm_latency() call to changed, which keeps the meaning of the code the same but makes it obvious that every one of these calls is expected to happen.
--- drivers/gpu/drm/i915/intel_pm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/intel_pm.c +3 -3
@@ -2245,9 +2245,9 @@ static void snb_wm_latency_quirk(struct* The BIOS provided WM memory latency values are often * inadequate for high resolution displays. Adjust them. */ - changed =ilk_increase_wm_latency (dev_priv, dev_priv->wm.pri_latency,12 ) | -ilk_increase_wm_latency (dev_priv, dev_priv->wm.spr_latency,12 ) | -ilk_increase_wm_latency (dev_priv, dev_priv->wm.cur_latency,12 ); + changed =ilk_increase_wm_latency (dev_priv, dev_priv->wm.pri_latency,12 ); + changed |=ilk_increase_wm_latency (dev_priv, dev_priv->wm.spr_latency,12 ); + changed |=ilk_increase_wm_latency (dev_priv, dev_priv->wm.cur_latency,12 );if (!changed)return ;
Greg Kroah-Hartman
maintainerPATCH 8/114 media: uvcvideo: fix division by zero at stream start
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 8aa637bf6d70d2fb2ad4d708d8b9dd02b1c095df upstream.
Add the missing bulk-endpoint max-packet sanity check to uvc_video_start_transfer() to avoid division by zero in uvc_alloc_urb_buffers() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing).
Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")).
--- drivers/media/usb/uvc/uvc_video.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/media/usb/uvc/uvc_video.c +4 -0
@@ -1720,6 +1720,10 @@ static int uvc_init_video(struct uvc_strif (ep ==NULL )return -EIO ; +/* Reject broken descriptors. */ +if (usb_endpoint_maxp (&ep->desc) ==0 ) +return -EIO ; + ret =uvc_init_video_bulk (stream, ep, gfp_flags); }
Greg Kroah-Hartman
maintainerPATCH 9/114 rtlwifi: rtl8192cu: Fix WARNING when calling local_irq_restore() with interrupts enabled
In reply to Greg Kroah-HartmanFrom: Larry Finger <[email protected]>
commit 8b144dedb928e4e2f433a328d58f44c3c098d63e upstream.
Syzbot reports the following WARNING:
[200~raw_local_irq_restore() called with IRQs enabled
WARNING: CPU: 1 PID: 1206 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10
Hardware initialization for the rtl8188cu can run for as long as 350 ms, and the routine may be called with interrupts disabled. To avoid locking the machine for this long, the current routine saves the interrupt flags and enables local interrupts. The problem is that it restores the flags at the end without disabling local interrupts first.
This patch fixes commit a53268be0cb9 ("rtlwifi: rtl8192cu: Fix too long disable of IRQs").
--- drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c +1 -0
@@ -1062,6 +1062,7 @@ int rtl92cu_hw_init(struct ieee80211_hw_InitPABias (hw);rtl92c_dm_init (hw); exit: +local_irq_disable ();local_irq_restore (flags);return err; }
Greg Kroah-Hartman
maintainerPATCH 10/114 HID: uhid: Fix worker destroying device without any protection
In reply to Greg Kroah-HartmanFrom: Jann Horn <[email protected]>
commit 4ea5763fb79ed89b3bdad455ebf3f33416a81624 upstream.
uhid has to run hid_add_device() from workqueue context while allowing parallel use of the userspace API (which is protected with ->devlock). But hid_add_device() can fail. Currently, that is handled by immediately destroying the associated HID device, without using ->devlock - but if there are concurrent requests from userspace, that's wrong and leads to NULL dereferences and/or memory corruption (via use-after-free).
Fix it by leaving the HID device as-is in the worker. We can clean it up later, either in the UHID_DESTROY command handler or in the ->release() handler.
--- drivers/hid/uhid.c | 29 +++++++++++++++++++++++++---- 1 file changed, 25 insertions(+), 4 deletions(-)
drivers/hid/uhid.c +25 -4
@@ -33,11 +33,22 @@struct uhid_device {struct mutex devlock; + +/* This flag tracks whether the HID device is usable for commands from +* userspace. The flag is already set before hid_add_device(), which +* runs in workqueue context, to allow hid_add_device() to communicate +* with userspace. +* However, if hid_add_device() fails, the flag is cleared without +* holding devlock. +* We guarantee that if @running changes from true to false while you're +* holding @devlock, it's still fine to access @hid. +*/ bool running;__u8 *rd_data;uint rd_size; +/* When this is NULL, userspace may use UHID_CREATE/UHID_CREATE2. */ struct hid_device *hid;struct uhid_event input_buf;
@@ -68,9 +79,18 @@ static void uhid_device_add_worker(strucif (ret) {hid_err (uhid->hid,"Cannot register HID device: error %d\n" , ret); -hid_destroy_device (uhid->hid); - uhid->hid =NULL ; +/* We used to call hid_destroy_device() here, but that's really +* messy to get right because we have to coordinate with +* concurrent writes from userspace that might be in the middle +* of using uhid->hid. +* Just leave uhid->hid as-is for now, and clean it up when +* userspace tries to close or reinitialize the uhid instance. +* +* However, we do have to clear the ->running flag and do a +* wakeup to make sure userspace knows that the device is gone. +*/ uhid->running = false; +wake_up_interruptible (&uhid->report_wait); } }
@@ -479,7 +499,7 @@ static int uhid_dev_create2(struct uhid_void *rd_data;int ret; -if (uhid->running) +if (uhid->hid)return -EALREADY ; rd_size = ev->u.create2.rd_size;
@@ -560,7 +580,7 @@ static int uhid_dev_create(struct uhid_dstatic int uhid_dev_destroy (struct uhid_device *uhid) { -if (!uhid->running) +if (!uhid->hid)return -EINVAL ; uhid->running = false;
@@ -569,6 +589,7 @@ static int uhid_dev_destroy(struct uhid_cancel_work_sync (&uhid->worker);hid_destroy_device (uhid->hid); + uhid->hid =NULL ;kfree (uhid->rd_data);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 11/114 nfc: llcp: fix NULL error pointer dereference on sendmsg() after failed bind()
In reply to Greg Kroah-HartmanFrom: Krzysztof Kozlowski <[email protected]>
commit dded08927ca3c31a5c37f8e7f95fe98770475dd4 upstream.
Syzbot detected a NULL pointer dereference of nfc_llcp_sock->dev pointer (which is a 'struct nfc_dev *') with calls to llcp_sock_sendmsg() after a failed llcp_sock_bind(). The message being sent is a SOCK_DGRAM.
KASAN report:
BUG: KASAN: null-ptr-deref in nfc_alloc_send_skb+0x2d/0xc0 Read of size 4 at addr 00000000000005c8 by task llcp_sock_nfc_a/899 CPU: 5 PID: 899 Comm: llcp_sock_nfc_a Not tainted 5.16.0-rc6-next-20211224-00001-gc6437fbf18b0 #125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x45/0x59 ? nfc_alloc_send_skb+0x2d/0xc0 __kasan_report.cold+0x117/0x11c ? mark_lock+0x480/0x4f0 ? nfc_alloc_send_skb+0x2d/0xc0 kasan_report+0x38/0x50 nfc_alloc_send_skb+0x2d/0xc0 nfc_llcp_send_ui_frame+0x18c/0x2a0 ? nfc_llcp_send_i_frame+0x230/0x230 ? __local_bh_enable_ip+0x86/0xe0 ? llcp_sock_connect+0x470/0x470 ? llcp_sock_connect+0x470/0x470 sock_sendmsg+0x8e/0xa0 ____sys_sendmsg+0x253/0x3f0 ...
The issue was visible only with multiple simultaneous calls to bind() and sendmsg(), which resulted in most of the bind() calls to fail. The bind() was failing on checking if there is available WKS/SDP/SAP (respective bit in 'struct nfc_llcp_local' fields). When there was no available WKS/SDP/SAP, the bind returned error but the sendmsg() to such socket was able to trigger mentioned NULL pointer dereference of nfc_llcp_sock->dev.
The code looks simply racy and currently it protects several paths against race with checks for (!nfc_llcp_sock->local) which is NULL-ified in error paths of bind(). The llcp_sock_sendmsg() did not have such check but called function nfc_llcp_send_ui_frame() had, although not protected with lock_sock().
Therefore the race could look like (same socket is used all the time):
CPU0 CPU1
==== ====
llcp_sock_bind()
- lock_sock()
- success
- release_sock()
- return 0
llcp_sock_sendmsg()
- lock_sock()
- release_sock()
llcp_sock_bind(), same socket
- lock_sock()
- error
- nfc_llcp_send_ui_frame()
- if (!llcp_sock->local)
- llcp_sock->local = NULL
- nfc_put_device(dev)
- dereference llcp_sock->dev
- release_sock()
- return -ERRNO
The nfc_llcp_send_ui_frame() checked llcp_sock->local outside of the lock, which is racy and ineffective check. Instead, its caller llcp_sock_sendmsg(), should perform the check inside lock_sock().
--- net/nfc/llcp_sock.c | 5 +++++ 1 file changed, 5 insertions(+)
net/nfc/llcp_sock.c +5 -0
@@ -790,6 +790,11 @@ static int llcp_sock_sendmsg(struct socklock_sock (sk); +if (!llcp_sock->local) { +release_sock (sk); +return -ENODEV ; + } +if (sk->sk_type ==SOCK_DGRAM ) { DECLARE_SOCKADDR(struct sockaddr_nfc_llcp *, addr, msg->msg_name);
Greg Kroah-Hartman
maintainerPATCH 12/114 rtc: cmos: take rtc_lock while reading from CMOS
In reply to Greg Kroah-HartmanFrom: Mateusz Jończyk <[email protected]>
commit 454f47ff464325223129b9b5b8d0b61946ec704d upstream.
Reading from the CMOS involves writing to the index register and then reading from the data register. Therefore access to the CMOS has to be serialized with rtc_lock. This invocation of CMOS_READ was not serialized, which could cause trouble when other code is accessing CMOS at the same time.
Use spin_lock_irq() like the rest of the function.
Nothing in kernel modifies the RTC_DM_BINARY bit, so there could be a separate pair of spin_lock_irq() / spin_unlock_irq() before doing the math.
--- drivers/rtc/rtc-cmos.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/rtc/rtc-cmos.c +3 -0
@@ -343,7 +343,10 @@ static int cmos_set_alarm(struct device min = t->time.tm_min; sec = t->time.tm_sec; +spin_lock_irq (&rtc_lock); rtc_control =CMOS_READ (RTC_CONTROL ); +spin_unlock_irq (&rtc_lock); +if (!(rtc_control &RTC_DM_BINARY ) ||RTC_ALWAYS_BCD ) {/* Writing 0xff means "don't care" or "match all". */ mon = (mon <=12 ) ?bin2bcd (mon) :0xff ;
Greg Kroah-Hartman
maintainerPATCH 13/114 media: mceusb: fix control-message timeouts
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 16394e998cbb050730536bdf7e89f5a70efbd974 upstream.
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ.
--- drivers/media/rc/mceusb.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/media/rc/mceusb.c +4 -4
@@ -1118,7 +1118,7 @@ static void mceusb_gen1_init(struct mceu*/ ret =usb_control_msg (ir->usbdev,usb_rcvctrlpipe (ir->usbdev,0 ),USB_REQ_SET_ADDRESS ,USB_TYPE_VENDOR ,0 ,0 , - data,USB_CTRL_MSG_SZ ,HZ *3 ); + data,USB_CTRL_MSG_SZ ,3000 );dev_dbg (dev,"set address - ret = %d" , ret);dev_dbg (dev,"set address - data[0] = %d, data[1] = %d" , data[0 ], data[1 ]);
@@ -1126,20 +1126,20 @@ static void mceusb_gen1_init(struct mceu/* set feature: bit rate 38400 bps */ ret =usb_control_msg (ir->usbdev,usb_sndctrlpipe (ir->usbdev,0 ),USB_REQ_SET_FEATURE ,USB_TYPE_VENDOR , -0xc04e ,0x0000 ,NULL ,0 ,HZ *3 ); +0xc04e ,0x0000 ,NULL ,0 ,3000 );dev_dbg (dev,"set feature - ret = %d" , ret);/* bRequest 4: set char length to 8 bits */ ret =usb_control_msg (ir->usbdev,usb_sndctrlpipe (ir->usbdev,0 ),4 ,USB_TYPE_VENDOR , -0x0808 ,0x0000 ,NULL ,0 ,HZ *3 ); +0x0808 ,0x0000 ,NULL ,0 ,3000 );dev_dbg (dev,"set char length - retB = %d" , ret);/* bRequest 2: set handshaking to use DTR/DSR */ ret =usb_control_msg (ir->usbdev,usb_sndctrlpipe (ir->usbdev,0 ),2 ,USB_TYPE_VENDOR , -0x0000 ,0x0100 ,NULL ,0 ,HZ *3 ); +0x0000 ,0x0100 ,NULL ,0 ,3000 );dev_dbg (dev,"set handshake - retC = %d" , ret);/* device resume */
Greg Kroah-Hartman
maintainerPATCH 14/114 media: em28xx: fix control-message timeouts
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit d9b7e8df3aa9b8c10708aab60e72e79ac08237e4 upstream.
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ.
--- drivers/media/usb/em28xx/em28xx-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/media/usb/em28xx/em28xx-core.c +2 -2
@@ -99,7 +99,7 @@ int em28xx_read_reg_req_len(struct em28xmutex_lock (&dev->ctrl_urb_lock); ret =usb_control_msg (dev->udev, pipe, req,USB_DIR_IN |USB_TYPE_VENDOR |USB_RECIP_DEVICE , -0x0000 , reg, dev->urb_buf, len,HZ ); +0x0000 , reg, dev->urb_buf, len,1000 );if (ret <0 ) {if (reg_debug)printk (" failed!\n" );
@@ -182,7 +182,7 @@ int em28xx_write_regs_req(struct em28xxmemcpy (dev->urb_buf, buf, len); ret =usb_control_msg (dev->udev, pipe, req,USB_DIR_OUT |USB_TYPE_VENDOR |USB_RECIP_DEVICE , -0x0000 , reg, dev->urb_buf, len,HZ ); +0x0000 , reg, dev->urb_buf, len,1000 );mutex_unlock (&dev->ctrl_urb_lock);if (ret <0 )
Greg Kroah-Hartman
maintainerPATCH 15/114 media: dib0700: fix undefined behavior in tuner shutdown
In reply to Greg Kroah-HartmanFrom: Michael Kuron <[email protected]>
commit f7b77ebe6d2f49c7747b2d619586d1aa33f9ea91 upstream.
This fixes a problem where closing the tuner would leave it in a state where it would not tune to any channel when reopened. This problem was discovered as part of https://github.com/hselasky/webcamd/issues/16.
Since adap->id is 0 or 1, this bit-shift overflows, which is undefined behavior. The driver still worked in practice as the overflow would in most environments result in 0, which rendered the line a no-op. When running the driver as part of webcamd however, the overflow could lead to 0xff due to optimizations by the compiler, which would, in the end, improperly shut down the tuner.
The bug is a regression introduced in the commit referenced below. The present patch causes identical behavior to before that commit for adap->id equal to 0 or 1. The driver does not contain support for dib0700 devices with more adapters, assuming such even exist.
Tests have been performed with the Xbox One Digital TV Tuner on amd64. Not all dib0700 devices are expected to be affected by the regression; this code path is only taken by those with incorrect endpoint numbers.
--- drivers/media/usb/dvb-usb/dib0700_core.c | 2 -- 1 file changed, 2 deletions(-)
drivers/media/usb/dvb-usb/dib0700_core.c +0 -2
@@ -583,8 +583,6 @@ int dib0700_streaming_ctrl(struct dvb_usdeb_info ("the endpoint number (%i) is not correct, use the adapter id instead" , adap->fe_adap[0 ].stream.props.endpoint);if (onoff) st->channel_state |=1 << (adap->id); -else - st->channel_state |=1 << ~(adap->id); }else {if (onoff) st->channel_state |=1 << (adap->fe_adap[0 ].stream.props.endpoint-2 );
Greg Kroah-Hartman
maintainerPATCH 16/114 media: pvrusb2: fix control-message timeouts
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit b82bf9b9dc305d7d3d93eab106d70dbf2171b43e upstream.
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ.
--- drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/media/usb/pvrusb2/pvrusb2-hdw.c +4 -4
@@ -1488,7 +1488,7 @@ static int pvr2_upload_firmware1(structfor (address =0 ; address < fwsize; address +=0x800 ) {memcpy (fw_ptr, fw_entry->data + address,0x800 ); ret +=usb_control_msg (hdw->usb_dev, pipe,0xa0 ,0x40 , address, -0 , fw_ptr,0x800 ,HZ ); +0 , fw_ptr,0x800 ,1000 ); }trace_firmware ("Upload done, releasing device's CPU" );
@@ -1627,7 +1627,7 @@ int pvr2_upload_firmware2(struct pvr2_hd ((u32 *)fw_ptr)[icnt] =swab32 (((u32 *)fw_ptr)[icnt]); ret |=usb_bulk_msg (hdw->usb_dev, pipe, fw_ptr,bcnt, - &actual_length,HZ ); + &actual_length,1000 ); ret |= (actual_length != bcnt);if (ret)break ; fw_done += bcnt;
@@ -3491,7 +3491,7 @@ void pvr2_hdw_cpufw_set_enabled(struct p0xa0 ,0xc0 , address,0 , hdw->fw_buffer+address, - 0x800,HZ); + 0x800,1000);if (ret <0 )break ; }
@@ -4017,7 +4017,7 @@ void pvr2_hdw_cpureset_assert(struct pvr/* Write the CPUCS register on the 8051. The lsb of the register is the reset bit; a 1 asserts reset while a 0 clears it. */ pipe =usb_sndctrlpipe (hdw->usb_dev,0 ); - ret =usb_control_msg (hdw->usb_dev,pipe,0xa0 ,0x40 ,0xe600 ,0 ,da,1 ,HZ ); + ret =usb_control_msg (hdw->usb_dev,pipe,0xa0 ,0x40 ,0xe600 ,0 ,da,1 ,1000 );if (ret <0 ) {pvr2_trace (PVR2_TRACE_ERROR_LEGS ,"cpureset_assert(%d) error=%d" ,val,ret);
Greg Kroah-Hartman
maintainerPATCH 17/114 media: stk1160: fix control-message timeouts
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 6aa6e70cdb5b863a57bad61310bf89b6617a5d2d upstream.
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ.
--- drivers/media/usb/stk1160/stk1160-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/media/usb/stk1160/stk1160-core.c +2 -2
@@ -76,7 +76,7 @@ int stk1160_read_reg(struct stk1160 *devreturn -ENOMEM ; ret =usb_control_msg (dev->udev, pipe,0x00 ,USB_DIR_IN |USB_TYPE_VENDOR |USB_RECIP_DEVICE , -0x00 , reg, buf,sizeof (u8),HZ ); +0x00 , reg, buf,sizeof (u8),1000 );if (ret <0 ) {stk1160_err ("read failed on reg 0x%x (%d)\n" , reg, ret);
@@ -96,7 +96,7 @@ int stk1160_write_reg(struct stk1160 *de ret =usb_control_msg (dev->udev, pipe,0x01 ,USB_DIR_OUT |USB_TYPE_VENDOR |USB_RECIP_DEVICE , - value, reg,NULL ,0 ,HZ ); + value, reg,NULL ,0 ,1000 );if (ret <0 ) {stk1160_err ("write failed on reg 0x%x (%d)\n" , reg, ret);
Greg Kroah-Hartman
maintainerPATCH 18/114 can: softing_cs: softingcs_probe(): fix memleak on registration failure
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit ced4913efb0acc844ed65cc01d091a85d83a2082 upstream.
In case device registration fails during probe, the driver state and the embedded platform device structure needs to be freed using platform_device_put() to properly free all resources (e.g. the device name).
--- drivers/net/can/softing/softing_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/can/softing/softing_cs.c +1 -1
@@ -304,7 +304,7 @@ static int softingcs_probe(struct pcmciareturn 0 ; platform_failed: -kfree (dev); +platform_device_put (pdev); mem_failed: pcmcia_bad: pcmcia_failed:
Greg Kroah-Hartman
maintainerPATCH 19/114 PCI: Add function 1 DMA alias quirk for Marvell 88SE9125 SATA controller
In reply to Greg Kroah-HartmanFrom: Yifeng Li <[email protected]>
commit e445375882883f69018aa669b67cbb37ec873406 upstream.
Like other SATA controller chips in the Marvell 88SE91xx series, the Marvell 88SE9125 has the same DMA requester ID hardware bug that prevents it from working under IOMMU. Add it to the list of devices that need the quirk.
Without this patch, device initialization fails with DMA errors:
ata8: softreset failed (1st FIS failed)
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Write NO_PASID] Request device [03:00.1] fault addr 0xfffc0000 [fault reason 0x02] Present bit in context entry is clear
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Read NO_PASID] Request device [03:00.1] fault addr 0xfffc0000 [fault reason 0x02] Present bit in context entry is clear
After applying the patch, the controller can be successfully initialized:
ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 330)
ata8.00: ATAPI: PIONEER BD-RW BDR-207M, 1.21, max UDMA/100
ata8.00: configured for UDMA/100
scsi 7:0:0:0: CD-ROM PIONEER BD-RW BDR-207M 1.21 PQ: 0 ANSI: 5
--- drivers/pci/quirks.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/pci/quirks.c +3 -0
@@ -3657,6 +3657,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_M quirk_dma_func1_alias);DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_MARVELL_EXT ,0x9123 , quirk_dma_func1_alias); +/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c136 */ +DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_MARVELL_EXT ,0x9125 , + quirk_dma_func1_alias);DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_MARVELL_EXT ,0x9128 , quirk_dma_func1_alias);/* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c14 */
Greg Kroah-Hartman
maintainerPATCH 20/114 Bluetooth: cmtp: fix possible panic when cmtp_init_sockets() fails
In reply to Greg Kroah-HartmanFrom: Wang Hai <[email protected]>
[ Upstream commit 2a7ca7459d905febf519163bd9e3eed894de6bb7 ]
I got a kernel BUG report when doing fault injection test:
------------[ cut here ]------------ kernel BUG at lib/list_debug.c:45! ... RIP: 0010:__list_del_entry_valid.cold+0x12/0x4d ... Call Trace: proto_unregister+0x83/0x220 cmtp_cleanup_sockets+0x37/0x40 [cmtp] cmtp_exit+0xe/0x1f [cmtp] do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae
If cmtp_init_sockets() in cmtp_init() fails, cmtp_init() still returns success. This will cause a kernel bug when accessing uncreated ctmp related data when the module exits.
--- net/bluetooth/cmtp/core.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
net/bluetooth/cmtp/core.c +1 -3
@@ -500,9 +500,7 @@ static int __init cmtp_init(void) {BT_INFO ("CMTP (CAPI Emulation) ver %s" ,VERSION ); -cmtp_init_sockets (); - -return 0 ; +return cmtp_init_sockets (); } static void __exit cmtp_exit(void)
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 21/114 Bluetooth: stop proccessing malicious adv data
In reply to Greg Kroah-HartmanFrom: Pavel Skripkin <[email protected]>
[ Upstream commit 3a56ef719f0b9682afb8a86d64b2399e36faa4e6 ]
Syzbot reported slab-out-of-bounds read in hci_le_adv_report_evt(). The problem was in missing validaion check.
We should check if data is not malicious and we can read next data block. If we won't check ptr validness, code can read a way beyond skb->end and it can cause problems, of course.
--- net/bluetooth/hci_event.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
net/bluetooth/hci_event.c +7 -1
@@ -4940,7 +4940,8 @@ static void hci_le_adv_report_evt(struct hci_dev *hdev, struct sk_buff *skb)struct hci_ev_le_advertising_info *ev = ptr;s8 rssi; -if (ev->length <=HCI_MAX_AD_LENGTH ) { +if (ev->length <=HCI_MAX_AD_LENGTH && + ev->data + ev->length <=skb_tail_pointer (skb)) { rssi = ev->data[ev->length]; process_adv_report(hdev, ev->evt_type, &ev->bdaddr, ev->bdaddr_type, NULL, 0, rssi,
@@ -4950,6 +4951,11 @@ static void hci_le_adv_report_evt(struct hci_dev *hdev, struct sk_buff *skb) } ptr +=sizeof (*ev) + ev->length +1 ; + +if (ptr > (void *)skb_tail_pointer (skb) -sizeof (*ev)) { +bt_dev_err (hdev,"Malicious advertising data. Stopping processing" ); +break ; + } }hci_dev_unlock (hdev);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 22/114 crypto: qce - fix uaf on qce_ahash_register_one
In reply to Greg Kroah-HartmanFrom: Chengfeng Ye <[email protected]>
[ Upstream commit b4cb4d31631912842eb7dce02b4350cbb7562d5e ]
Pointer base points to sub field of tmpl, it
is dereferenced after tmpl is freed. Fix
this by accessing base before free tmpl.
--- drivers/crypto/qce/sha.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/crypto/qce/sha.c +1 -1
@@ -539,8 +539,8 @@ static int qce_ahash_register_one(const struct qce_ahash_def *def, ret =crypto_register_ahash (alg);if (ret) { -kfree (tmpl);dev_err (qce->dev,"%s registration failed\n" , base->cra_name); +kfree (tmpl);return ret; }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 23/114 tty: serial: atmel: Check return code of dmaengine_submit()
In reply to Greg Kroah-HartmanFrom: Tudor Ambarus <[email protected]>
[ Upstream commit 1e67bd2b8cb90b66e89562598e9c2046246832d3 ]
The tx_submit() method of struct dma_async_tx_descriptor is entitled to do sanity checks and return errors if encountered. It's not the case for the DMA controller drivers that this client is using (at_h/xdmac), because they currently don't do sanity checks and always return a positive cookie at tx_submit() method. In case the controller drivers will implement sanity checks and return errors, print a message so that the client will be informed that something went wrong at tx_submit() level.
--- drivers/tty/serial/atmel_serial.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/tty/serial/atmel_serial.c +10 -0
@@ -928,6 +928,11 @@ static void atmel_tx_dma(struct uart_port *port) desc->callback = atmel_complete_tx_dma; desc->callback_param = atmel_port; atmel_port->cookie_tx =dmaengine_submit (desc); +if (dma_submit_error (atmel_port->cookie_tx)) { +dev_err (port->dev,"dma_submit_error %d\n" , + atmel_port->cookie_tx); +return ; + } }if (uart_circ_chars_pending (xmit) <WAKEUP_CHARS )
@@ -1186,6 +1191,11 @@ static int atmel_prepare_rx_dma(struct uart_port *port) desc->callback_param = port; atmel_port->desc_rx = desc; atmel_port->cookie_rx =dmaengine_submit (desc); +if (dma_submit_error (atmel_port->cookie_rx)) { +dev_err (port->dev,"dma_submit_error %d\n" , + atmel_port->cookie_rx); + goto chan_err; + }return 0 ;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 24/114 tty: serial: atmel: Call dma_async_issue_pending()
In reply to Greg Kroah-HartmanFrom: Tudor Ambarus <[email protected]>
[ Upstream commit 4f4b9b5895614eb2e2b5f4cab7858f44bd113e1b ]
The driver wrongly assummed that tx_submit() will start the transfer, which is not the case, now that the at_xdmac driver is fixed. tx_submit is supposed to push the current transaction descriptor to a pending queue, waiting for issue_pending to be called. issue_pending must start the transfer, not tx_submit.
--- drivers/tty/serial/atmel_serial.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/tty/serial/atmel_serial.c +4 -0
@@ -933,6 +933,8 @@ static void atmel_tx_dma(struct uart_port *port) atmel_port->cookie_tx);return ; } + +dma_async_issue_pending (chan); }if (uart_circ_chars_pending (xmit) <WAKEUP_CHARS )
@@ -1197,6 +1199,8 @@ static int atmel_prepare_rx_dma(struct uart_port *port) goto chan_err; } +dma_async_issue_pending (atmel_port->chan_rx); +return 0 ; chan_err:
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 25/114 netfilter: bridge: add support for pppoe filtering
In reply to Greg Kroah-HartmanFrom: Florian Westphal <[email protected]>
[ Upstream commit 28b78ecffea8078d81466b2e01bb5a154509f1ba ]
This makes 'bridge-nf-filter-pppoe-tagged' sysctl work for bridged traffic.
Looking at the original commit it doesn't appear this ever worked:
static unsigned int br_nf_post_routing(unsigned int hook, struct sk_buff **pskb,
[..]
if (skb->protocol == htons(ETH_P_8021Q)) {
skb_pull(skb, VLAN_HLEN);
skb->network_header += VLAN_HLEN;
+ } else if (skb->protocol == htons(ETH_P_PPP_SES)) {
+ skb_pull(skb, PPPOE_SES_HLEN);
+ skb->network_header += PPPOE_SES_HLEN;
}
[..]
NF_HOOK(... POST_ROUTING, ...)... but the adjusted offsets are never restored.
The alternative would be to rip this code out for good, but otoh we'd have to keep this anyway for the vlan handling (which works because vlan tag info is in the skb, not the packet
payload).
--- net/bridge/br_netfilter_hooks.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
net/bridge/br_netfilter_hooks.c +3 -4
@@ -719,6 +719,9 @@ static int br_nf_dev_queue_xmit(struct net *net, struct sock *sk, struct sk_buffif (nf_bridge->frag_max_size && nf_bridge->frag_max_size < mtu) mtu = nf_bridge->frag_max_size; +nf_bridge_update_protocol (skb); +nf_bridge_push_encap_header (skb); +if (skb_is_gso (skb) || skb->len + mtu_reserved <= mtu) {nf_bridge_info_free (skb);return br_dev_queue_push_xmit (net, sk, skb);
@@ -736,8 +739,6 @@ static int br_nf_dev_queue_xmit(struct net *net, struct sock *sk, struct sk_buffIPCB (skb)->frag_max_size = nf_bridge->frag_max_size; -nf_bridge_update_protocol (skb); - data =this_cpu_ptr (&brnf_frag_data_storage); data->vlan_tci = skb->vlan_tci;
@@ -760,8 +761,6 @@ static int br_nf_dev_queue_xmit(struct net *net, struct sock *sk, struct sk_buffIP6CB (skb)->frag_max_size = nf_bridge->frag_max_size; -nf_bridge_update_protocol (skb); - data =this_cpu_ptr (&brnf_frag_data_storage); data->encap_size =nf_bridge_encap_header_len (skb); data->size =ETH_HLEN + data->encap_size;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 26/114 arm64: dts: qcom: msm8916: fix MMC controller aliases
In reply to Greg Kroah-HartmanFrom: Dmitry Baryshkov <[email protected]>
[ Upstream commit b0293c19d42f6d6951c2fab9a47fed50baf2c14d ]
Change sdhcN aliases to mmcN to make them actually work. Currently the board uses non-standard aliases sdhcN, which do not work, resulting in mmc0 and mmc1 hosts randomly changing indices between boots.
--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm64/boot/dts/qcom/msm8916.dtsi +2 -2
@@ -25,8 +25,8 @@ #size-cells = <2>; aliases { - sdhc1 = &sdhc_1; /* SDC1 eMMC slot */ - sdhc2 = &sdhc_2; /* SDC2 SD card slot */ + mmc0 = &sdhc_1; /* SDC1 eMMC slot */ + mmc1 = &sdhc_2; /* SDC2 SD card slot */ }; chosen { };
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 27/114 drm/amdgpu: Fix a NULL pointer dereference in amdgpu_connector_lcd_native_mode()
In reply to Greg Kroah-HartmanFrom: Zhou Qingyang <[email protected]>
[ Upstream commit b220110e4cd442156f36e1d9b4914bb9e87b0d00 ]
In amdgpu_connector_lcd_native_mode(), the return value of drm_mode_duplicate() is assigned to mode, and there is a dereference of it in amdgpu_connector_lcd_native_mode(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate().
Fix this bug add a check of mode.
This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug.
Builds with CONFIG_DRM_AMDGPU=m show no new warnings, and our static analyzer no longer warns about this code.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c +6 -0
@@ -404,6 +404,9 @@ amdgpu_connector_lcd_native_mode(struct drm_encoder *encoder) native_mode->vdisplay != 0 && native_mode->clock != 0) { mode =drm_mode_duplicate (dev, native_mode); +if (!mode) +return NULL ; + mode->type =DRM_MODE_TYPE_PREFERRED |DRM_MODE_TYPE_DRIVER ;drm_mode_set_name (mode);
@@ -418,6 +421,9 @@ amdgpu_connector_lcd_native_mode(struct drm_encoder *encoder)* simpler. */ mode =drm_cvt_mode (dev, native_mode->hdisplay, native_mode->vdisplay,60 , true, false, false); +if (!mode) +return NULL ; + mode->type =DRM_MODE_TYPE_PREFERRED |DRM_MODE_TYPE_DRIVER ;DRM_DEBUG_KMS ("Adding cvt approximation of native panel mode %s\n" , mode->name); }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 28/114 serial: amba-pl011: do not request memory region twice
In reply to Greg Kroah-HartmanFrom: Lino Sanfilippo <[email protected]>
[ Upstream commit d1180405c7b5c7a1c6bde79d5fc24fe931430737 ]
With commit 3873e2d7f63a ("drivers: PL011: refactor pl011_probe()") the function devm_ioremap() called from pl011_setup_port() was replaced with devm_ioremap_resource(). Since this function not only remaps but also requests the ports io memory region it now collides with the .config_port() callback which requests the same region at uart port registration.
Since devm_ioremap_resource() already claims the memory successfully, the request in .config_port() fails.
Later at uart port deregistration the attempt to release the unclaimed memory also fails. The failure results in a “Trying to free nonexistent resource" warning.
Fix these issues by removing the callbacks that implement the redundant memory allocation/release. Also make sure that changing the drivers io memory base address via TIOCSSERIAL is not allowed any more.
--- drivers/tty/serial/amba-pl011.c | 27 +++------------------------ 1 file changed, 3 insertions(+), 24 deletions(-)
drivers/tty/serial/amba-pl011.c +3 -24
@@ -1944,32 +1944,13 @@ static const char *pl011_type(struct uart_port *port)return uap->port.type ==PORT_AMBA ? uap->type :NULL ; } -/* -* Release the memory region(s) being used by 'port' -*/ -static void pl011_release_port (struct uart_port *port) -{ -release_mem_region (port->mapbase,SZ_4K ); -} - -/* -* Request the memory region(s) being used by 'port' -*/ -static int pl011_request_port (struct uart_port *port) -{ -return request_mem_region (port->mapbase,SZ_4K ,"uart-pl011" ) - !=NULL ?0 : -EBUSY ; -} -/* * Configure/autoconfigure the port. */ static void pl011_config_port (struct uart_port *port,int flags) { -if (flags &UART_CONFIG_TYPE ) { +if (flags &UART_CONFIG_TYPE ) port->type =PORT_AMBA ; -pl011_request_port (port); - } }/*
@@ -1984,6 +1965,8 @@ static int pl011_verify_port(struct uart_port *port, struct serial_struct *ser) ret = -EINVAL ;if (ser->baud_base <9600 ) ret = -EINVAL ; +if (port->mapbase != (unsigned long ) ser->iomem_base) + ret = -EINVAL ;return ret; }
@@ -2001,8 +1984,6 @@ static struct uart_ops amba_pl011_pops = { .flush_buffer = pl011_dma_flush_buffer, .set_termios = pl011_set_termios, .type = pl011_type, - .release_port = pl011_release_port, - .request_port = pl011_request_port, .config_port = pl011_config_port, .verify_port = pl011_verify_port,#ifdef CONFIG_CONSOLE_POLL
@@ -2032,8 +2013,6 @@ static const struct uart_ops sbsa_uart_pops = { .shutdown = sbsa_uart_shutdown, .set_termios = sbsa_uart_set_termios, .type = pl011_type, - .release_port = pl011_release_port, - .request_port = pl011_request_port, .config_port = pl011_config_port, .verify_port = pl011_verify_port,#ifdef CONFIG_CONSOLE_POLL
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 29/114 floppy: Fix hang in watchdog when disk is ejected
In reply to Greg Kroah-HartmanFrom: Tasos Sahanidis <[email protected]>
[ Upstream commit fb48febce7e30baed94dd791e19521abd2c3fd83 ]
When the watchdog detects a disk change, it calls cancel_activity(), which in turn tries to cancel the fd_timer delayed work.
In the above scenario, fd_timer_fn is set to fd_watchdog(), meaning it is trying to cancel its own work.
This results in a hang as cancel_delayed_work_sync() is waiting for the watchdog (itself) to return, which never happens.
This can be reproduced relatively consistently by attempting to read a broken floppy, and ejecting it while IO is being attempted and retried.
To resolve this, this patch calls cancel_delayed_work() instead, which cancels the work without waiting for the watchdog to return and finish.
Before this regression was introduced, the code in this section used del_timer(), and not del_timer_sync() to delete the watchdog timer.
--- drivers/block/floppy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/block/floppy.c +1 -1
@@ -994,7 +994,7 @@ static DECLARE_DELAYED_WORK(fd_timer, fd_timer_workfn);static void cancel_activity (void ) { do_floppy =NULL ; -cancel_delayed_work_sync (&fd_timer); +cancel_delayed_work (&fd_timer);cancel_work_sync (&floppy_work); }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 30/114 media: dib8000: Fix a memleak in dib8000_init()
In reply to Greg Kroah-HartmanFrom: Zhou Qingyang <[email protected]>
[ Upstream commit 8dbdcc7269a83305ee9d677b75064d3530a48ee2 ]
In dib8000_init(), the variable fe is not freed or passed out on the failure of dib8000_identify(&state->i2c), which could lead to a memleak.
Fix this bug by adding a kfree of fe in the error path.
This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug.
Builds with CONFIG_DVB_DIB8000=m show no new warnings, and our static analyzer no longer warns about this code.
--- drivers/media/dvb-frontends/dib8000.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/media/dvb-frontends/dib8000.c +3 -1
@@ -4461,8 +4461,10 @@ static struct dvb_frontend *dib8000_init(struct i2c_adapter *i2c_adap, u8 i2c_ad state->timf_default = cfg->pll->timf; -if (dib8000_identify (&state->i2c) ==0 ) +if (dib8000_identify (&state->i2c) ==0 ) { +kfree (fe); goto error; + }dibx000_init_i2c_master (&state->i2c_master,DIB8000 , state->i2c.adap, state->i2c.addr);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 31/114 media: saa7146: mxb: Fix a NULL pointer dereference in mxb_attach()
In reply to Greg Kroah-HartmanFrom: Zhou Qingyang <[email protected]>
[ Upstream commit 0407c49ebe330333478440157c640fffd986f41b ]
In mxb_attach(dev, info), saa7146_vv_init() is called to allocate a new memory for dev->vv_data. saa7146_vv_release() will be called on failure of mxb_probe(dev). There is a dereference of dev->vv_data in saa7146_vv_release(), which could lead to a NULL pointer dereference on failure of saa7146_vv_init().
Fix this bug by adding a check of saa7146_vv_init().
This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug.
Builds with CONFIG_VIDEO_MXB=m show no new warnings, and our static analyzer no longer warns about this code.
--- drivers/media/pci/saa7146/mxb.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/media/pci/saa7146/mxb.c +7 -1
@@ -694,10 +694,16 @@ static struct saa7146_ext_vv vv_data;static int mxb_attach (struct saa7146_dev *dev,struct saa7146_pci_extension_data *info) {struct mxb *mxb; +int ret;DEB_EE ("dev:%p\n" , dev); -saa7146_vv_init (dev, &vv_data); + ret =saa7146_vv_init (dev, &vv_data); +if (ret) { +ERR ("Error in saa7146_vv_init()" ); +return ret; + } +if (mxb_probe (dev)) {saa7146_vv_release (dev);return -1 ;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 32/114 media: msi001: fix possible null-ptr-deref in msi001_probe()
In reply to Greg Kroah-HartmanFrom: Wang Hai <[email protected]>
[ Upstream commit 3d5831a40d3464eea158180eb12cbd81c5edfb6a ]
I got a null-ptr-deref report:
BUG: kernel NULL pointer dereference, address: 0000000000000060 ... RIP: 0010:v4l2_ctrl_auto_cluster+0x57/0x270 ... Call Trace: msi001_probe+0x13b/0x24b [msi001] spi_probe+0xeb/0x130
...
do_syscall_64+0x35/0xb0
In msi001_probe(), if the creation of control for bandwidth_auto fails, there will be a null-ptr-deref issue when it is used in v4l2_ctrl_auto_cluster().
Check dev->hdl.error before v4l2_ctrl_auto_cluster() to fix this bug.
--- drivers/media/tuners/msi001.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/media/tuners/msi001.c +7 -0
@@ -464,6 +464,13 @@ static int msi001_probe(struct spi_device *spi) V4L2_CID_RF_TUNER_BANDWIDTH_AUTO, 0, 1, 1, 1); dev->bandwidth =v4l2_ctrl_new_std (&dev->hdl, &msi001_ctrl_ops,V4L2_CID_RF_TUNER_BANDWIDTH ,200000 ,8000000 ,1 ,200000 ); +if (dev->hdl.error) { + ret = dev->hdl.error; +dev_err (&spi->dev,"Could not initialize controls\n" ); +/* control init failed, free handler */ + goto err_ctrl_handler_free; + } +v4l2_ctrl_auto_cluster (2 , &dev->bandwidth_auto,0 , false); dev->lna_gain =v4l2_ctrl_new_std (&dev->hdl, &msi001_ctrl_ops,V4L2_CID_RF_TUNER_LNA_GAIN ,0 ,1 ,1 ,1 );
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 33/114 usb: ftdi-elan: fix memory leak on device disconnect
In reply to Greg Kroah-HartmanFrom: Wei Yongjun <[email protected]>
[ Upstream commit 1646566b5e0c556f779180a8514e521ac735de1e ]
'ftdi' is alloced when probe device, but not free on device disconnect, this cause a memory leak as follows:
unreferenced object 0xffff88800d584000 (size 8400):
comm "kworker/0:2", pid 3809, jiffies 4295453055 (age 13.784s) hex dump (first 32 bytes):
00 40 58 0d 80 88 ff ff 00 40 58 0d 80 88 ff ff .@X......@X.....
00 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .............N..
backtrace:
[<000000000d47f947>] kmalloc_order_trace+0x19/0x110 mm/slab_common.c:960
[<000000008548ac68>] ftdi_elan_probe+0x8c/0x880 drivers/usb/misc/ftdi-elan.c:2647
[<000000007f73e422>] usb_probe_interface+0x31b/0x800 drivers/usb/core/driver.c:396
[<00000000fe8d07fc>] really_probe+0x299/0xc30 drivers/base/dd.c:517
[<0000000005da7d32>] __driver_probe_device+0x357/0x500 drivers/base/dd.c:751
[<000000003c2c9579>] driver_probe_device+0x4e/0x140 drivers/base/dd.c:781Fix it by freeing 'ftdi' after nobody use it.
--- drivers/usb/misc/ftdi-elan.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/misc/ftdi-elan.c +1 -0
@@ -209,6 +209,7 @@ static void ftdi_elan_delete(struct kref *kref)mutex_unlock (&ftdi_module_lock);kfree (ftdi->bulk_in_buffer); ftdi->bulk_in_buffer =NULL ; +kfree (ftdi); }static void ftdi_elan_put_kref (struct usb_ftdi *ftdi)
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 34/114 pcmcia: rsrc_nonstatic: Fix a NULL pointer dereference in __nonstatic_find_io_region()
In reply to Greg Kroah-HartmanFrom: Zhou Qingyang <[email protected]>
[ Upstream commit ca0fe0d7c35c97528bdf621fdca75f13157c27af ]
In __nonstatic_find_io_region(), pcmcia_make_resource() is assigned to res and used in pci_bus_alloc_resource(). There is a dereference of res in pci_bus_alloc_resource(), which could lead to a NULL pointer dereference on failure of pcmcia_make_resource().
Fix this bug by adding a check of res.
This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug.
Builds with CONFIG_PCCARD_NONSTATIC=y show no new warnings, and our static analyzer no longer warns about this code.
--- drivers/pcmcia/rsrc_nonstatic.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/pcmcia/rsrc_nonstatic.c +3 -0
@@ -693,6 +693,9 @@ static struct resource *__nonstatic_find_io_region(struct pcmcia_socket *s,unsigned long min = base;int ret; +if (!res) +return NULL ; + data.mask = align -1 ; data.offset = base & data.mask; data.map = &s_data->io_db;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 35/114 pcmcia: rsrc_nonstatic: Fix a NULL pointer dereference in nonstatic_find_mem_region()
In reply to Greg Kroah-HartmanFrom: Zhou Qingyang <[email protected]>
[ Upstream commit 977d2e7c63c3d04d07ba340b39987742e3241554 ]
In nonstatic_find_mem_region(), pcmcia_make_resource() is assigned to res and used in pci_bus_alloc_resource(). There a dereference of res in pci_bus_alloc_resource(), which could lead to a NULL pointer dereference on failure of pcmcia_make_resource().
Fix this bug by adding a check of res.
This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug.
Builds with CONFIG_PCCARD_NONSTATIC=y show no new warnings, and our static analyzer no longer warns about this code.
--- drivers/pcmcia/rsrc_nonstatic.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/pcmcia/rsrc_nonstatic.c +3 -0
@@ -815,6 +815,9 @@ static struct resource *nonstatic_find_mem_region(u_long base, u_long num,unsigned long min, max;int ret, i, j; +if (!res) +return NULL ; + low = low || !(s->features &SS_CAP_PAGE_REGS ); data.mask = align -1 ;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 36/114 ppp: ensure minimum packet size in ppp_write()
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit 44073187990d5629804ce0627525f6ea5cfef171 ]
It seems pretty clear ppp layer assumed user space would always be kind to provide enough data in their write() to a ppp device.
This patch makes sure user provides at least 2 bytes.
It adds PPP_PROTO_LEN macro that could replace in net-next many occurrences of hard-coded 2 value.
I replaced only one occurrence to ease backports to stable kernels.
The bug manifests in the following report:
BUG: KMSAN: uninit-value in ppp_send_frame+0x28d/0x27c0 drivers/net/ppp/ppp_generic.c:1740 ppp_send_frame+0x28d/0x27c0 drivers/net/ppp/ppp_generic.c:1740 __ppp_xmit_process+0x23e/0x4b0 drivers/net/ppp/ppp_generic.c:1640 ppp_xmit_process+0x1fe/0x480 drivers/net/ppp/ppp_generic.c:1661 ppp_write+0x5cb/0x5e0 drivers/net/ppp/ppp_generic.c:513 do_iter_write+0xb0c/0x1500 fs/read_write.c:853 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae
Uninit was created at:
slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] ppp_write+0x11d/0x5e0 drivers/net/ppp/ppp_generic.c:501 do_iter_write+0xb0c/0x1500 fs/read_write.c:853 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae
--- drivers/net/ppp/ppp_generic.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/net/ppp/ppp_generic.c +6 -1
@@ -70,6 +70,8 @@#define MPHDRLEN 6/* multilink protocol header length */ #define MPHDRLEN_SSN 4/* ditto with short sequence numbers */ +#define PPP_PROTO_LEN 2 +/* * An instance of /dev/ppp can be associated with either a ppp * interface unit or a ppp channel. In both cases, file->private_data
@@ -487,6 +489,9 @@ static ssize_t ppp_write(struct file *file, const char __user *buf,if (!pf)return -ENXIO ; +/* All PPP packets should start with the 2-byte protocol */ +if (count <PPP_PROTO_LEN ) +return -EINVAL ; ret = -ENOMEM ; skb =alloc_skb (count + pf->hdrlen,GFP_KERNEL );if (!skb)
@@ -1293,7 +1298,7 @@ ppp_send_frame(struct ppp *ppp, struct sk_buff *skb) } ++ppp->stats64.tx_packets; - ppp->stats64.tx_bytes += skb->len -2 ; + ppp->stats64.tx_bytes += skb->len -PPP_PROTO_LEN ;switch (proto) {case PPP_IP :
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 37/114 spi: spi-meson-spifc: Add missing pm_runtime_disable() in meson_spifc_probe
In reply to Greg Kroah-HartmanFrom: Miaoqian Lin <[email protected]>
[ Upstream commit 69c1b87516e327a60b39f96b778fe683259408bf ]
If the probe fails, we should use pm_runtime_disable() to balance pm_runtime_enable().
Add missing pm_runtime_disable() for meson_spifc_probe.
--- drivers/spi/spi-meson-spifc.c | 1 + 1 file changed, 1 insertion(+)
drivers/spi/spi-meson-spifc.c +1 -0
@@ -357,6 +357,7 @@ static int meson_spifc_probe(struct platform_device *pdev)return 0 ; out_clk:clk_disable_unprepare (spifc->clk); +pm_runtime_disable (spifc->dev); out_err:spi_master_put (master);return ret;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 38/114 can: softing: softing_startstop(): fix set but not used variable warning
In reply to Greg Kroah-HartmanFrom: Marc Kleine-Budde <[email protected]>
[ Upstream commit 370d988cc529598ebaec6487d4f84c2115dc696b ]
In the function softing_startstop() the variable error_reporting is assigned but not used. The code that uses this variable is commented out. Its stated that the functionality is not finally verified.
To fix the warning:
| drivers/net/can/softing/softing_fw.c:424:9: error: variable 'error_reporting' set but not used [-Werror,-Wunused-but-set-variable]
remove the comment, activate the code, but add a "0 &&" to the if expression and rely on the optimizer rather than the preprocessor to remove the code.
--- drivers/net/can/softing/softing_fw.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/net/can/softing/softing_fw.c +6 -5
@@ -576,18 +576,19 @@ int softing_startstop(struct net_device *dev, int up)if (ret <0 ) goto failed; } -/* enable_error_frame */ -/* + +/* enable_error_frame +* * Error reporting is switched off at the moment since * the receiving of them is not yet 100% verified * This should be enabled sooner or later -* -if (error_reporting) { +*/ +if (0 && error_reporting) { ret =softing_fct_cmd (card,51 ,"enable_error_frame" );if (ret <0 ) goto failed; } -*/ +/* initialize interface */ iowrite16 (1 , &card->dpram[DPRAM_FCT_PARAM +2 ]);iowrite16 (1 , &card->dpram[DPRAM_FCT_PARAM +4 ]);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 39/114 can: xilinx_can: xcan_probe(): check for error irq
In reply to Greg Kroah-HartmanFrom: Jiasheng Jiang <[email protected]>
[ Upstream commit c6564c13dae25cd7f8e1de5127b4da4500ee5844 ]
For the possible failure of the platform_get_irq(), the returned irq could be error number and will finally cause the failure of the request_irq().
Consider that platform_get_irq() can now in certain cases return -EPROBE_DEFER, and the consequences of letting request_irq() effectively convert that into -EINVAL, even at probe time rather than later on. So it might be better to check just now.
--- drivers/net/can/xilinx_can.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/net/can/xilinx_can.c +6 -1
@@ -1284,7 +1284,12 @@ static int xcan_probe(struct platform_device *pdev)spin_lock_init (&priv->tx_lock);/* Get IRQ for the device */ - ndev->irq =platform_get_irq (pdev,0 ); + ret =platform_get_irq (pdev,0 ); +if (ret <0 ) + goto err_free; + + ndev->irq = ret; + ndev->flags |=IFF_ECHO ;/* We support local echo */ platform_set_drvdata (pdev, ndev);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 40/114 pcmcia: fix setting of kthread task states
In reply to Greg Kroah-HartmanFrom: Dominik Brodowski <[email protected]>
[ Upstream commit fbb3485f1f931102d8ba606f1c28123f5b48afa3 ]
We need to set TASK_INTERRUPTIBLE before calling kthread_should_stop(). Otherwise, kthread_stop() might see that the pccardd thread is still in TASK_RUNNING state and fail to wake it up.
Additionally, we only need to set the state back to TASK_RUNNING if kthread_should_stop() breaks the loop.
--- drivers/pcmcia/cs.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
drivers/pcmcia/cs.c +3 -5
@@ -665,18 +665,16 @@ static int pccardd(void *__skt)if (events || sysfs_events)continue ; +set_current_state (TASK_INTERRUPTIBLE );if (kthread_should_stop ())break ; -set_current_state (TASK_INTERRUPTIBLE ); -schedule (); -/* make sure we are running */ -__set_current_state (TASK_RUNNING ); -try_to_freeze (); } +/* make sure we are running before we exit */ +__set_current_state (TASK_RUNNING );/* shut down socket, if a device is still present */ if (skt->state &SOCKET_PRESENT ) {
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 41/114 net: mcs7830: handle usb read errors properly
In reply to Greg Kroah-HartmanFrom: Pavel Skripkin <[email protected]>
[ Upstream commit d668769eb9c52b150753f1653f7f5a0aeb8239d2 ]
Syzbot reported uninit value in mcs7830_bind(). The problem was in missing validation check for bytes read via usbnet_read_cmd().
usbnet_read_cmd() internally calls usb_control_msg(), that returns number of bytes read. Code should validate that requested number of bytes was actually read.
So, this patch adds missing size validation check inside mcs7830_get_reg() to prevent uninit value bugs
--- drivers/net/usb/mcs7830.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/net/usb/mcs7830.c +10 -2
@@ -121,8 +121,16 @@ static const char driver_name[] = "MOSCHIP usb-ethernet driver";static int mcs7830_get_reg (struct usbnet *dev,u16 index,u16 size,void *data) { -return usbnet_read_cmd (dev,MCS7830_RD_BREQ ,MCS7830_RD_BMREQ , -0x0000 , index, data, size); +int ret; + + ret =usbnet_read_cmd (dev,MCS7830_RD_BREQ ,MCS7830_RD_BMREQ , +0x0000 , index, data, size); +if (ret <0 ) +return ret; +else if (ret < size) +return -ENODATA ; + +return ret; }static int mcs7830_set_reg (struct usbnet *dev,u16 index,u16 size,const void *data)
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 42/114 ext4: avoid trim error on fs with small groups
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
[ Upstream commit 173b6e383d2a204c9921ffc1eca3b87aa2106c33 ]
A user reported FITRIM ioctl failing for him on ext4 on some devices without apparent reason. After some debugging we've found out that these devices (being LVM volumes) report rather large discard granularity of 42MB and the filesystem had 1k blocksize and thus group size of 8MB. Because ext4 FITRIM implementation puts discard granularity into minlen, ext4_trim_fs() declared the trim request as invalid. However just silently doing nothing seems to be a more appropriate reaction to such combination of parameters since user did not specify anything wrong.
--- fs/ext4/ioctl.c | 2 -- fs/ext4/mballoc.c | 8 ++++++++ 2 files changed, 8 insertions(+), 2 deletions(-)
fs/ext4/ioctl.c +0 -2
@@ -610,8 +610,6 @@ resizefs_out: sizeof(range)))return -EFAULT ; - range.minlen =max ((unsigned int )range.minlen, - q->limits.discard_granularity); ret =ext4_trim_fs (sb, &range);if (ret <0 )return ret;
fs/ext4/mballoc.c +8 -0
@@ -5223,6 +5223,7 @@ out:*/ int ext4_trim_fs (struct super_block *sb,struct fstrim_range *range) { +struct request_queue *q =bdev_get_queue (sb->s_bdev);struct ext4_group_info *grp;ext4_group_t group, first_group, last_group;ext4_grpblk_t cnt =0 , first_cluster, last_cluster;
@@ -5241,6 +5242,13 @@ int ext4_trim_fs(struct super_block *sb, struct fstrim_range *range) start >= max_blks || range->len < sb->s_blocksize) return -EINVAL; +/* No point to try to trim less than discard granularity */ +if (range->minlen < q->limits.discard_granularity) { + minlen =EXT4_NUM_B2C (EXT4_SB (sb), + q->limits.discard_granularity >> sb->s_blocksize_bits); +if (minlen >EXT4_CLUSTERS_PER_GROUP (sb)) + goto out; + }if (end >= max_blks) end = max_blks -1 ;if (end <= first_data_blk)
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 43/114 ALSA: jack: Add missing rwsem around snd_ctl_remove() calls
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
[ Upstream commit 06764dc931848c3a9bc01a63bbf76a605408bb54 ]
snd_ctl_remove() has to be called with card->controls_rwsem held (when called after the card instantiation). This patch add the missing rwsem calls around it.
--- sound/core/jack.c | 3 +++ 1 file changed, 3 insertions(+)
sound/core/jack.c +3 -0
@@ -64,10 +64,13 @@ static int snd_jack_dev_free(struct snd_device *device)struct snd_card *card = device->card;struct snd_jack_kctl *jack_kctl, *tmp_jack_kctl; +down_write (&card->controls_rwsem);list_for_each_entry_safe (jack_kctl, tmp_jack_kctl, &jack->kctl_list, list) {list_del_init (&jack_kctl->list);snd_ctl_remove (card, jack_kctl->kctl); } +up_write (&card->controls_rwsem); +if (jack->private_free) jack->private_free (jack);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 44/114 ALSA: PCM: Add missing rwsem around snd_ctl_remove() calls
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
[ Upstream commit 5471e9762e1af4b7df057a96bfd46cc250979b88 ]
snd_ctl_remove() has to be called with card->controls_rwsem held (when called after the card instantiation). This patch add the missing rwsem calls around it.
--- sound/core/pcm.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
sound/core/pcm.c +5 -1
@@ -857,7 +857,11 @@ EXPORT_SYMBOL(snd_pcm_new_internal);static void free_chmap (struct snd_pcm_str *pstr) {if (pstr->chmap_kctl) { -snd_ctl_remove (pstr->pcm->card, pstr->chmap_kctl); +struct snd_card *card = pstr->pcm->card; + +down_write (&card->controls_rwsem); +snd_ctl_remove (card, pstr->chmap_kctl); +up_write (&card->controls_rwsem); pstr->chmap_kctl =NULL ; } }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 45/114 ALSA: hda: Add missing rwsem around snd_ctl_remove() calls
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
[ Upstream commit 80bd64af75b4bb11c0329bc66c35da2ddfb66d88 ]
snd_ctl_remove() has to be called with card->controls_rwsem held (when called after the card instantiation). This patch add the missing rwsem calls around it.
--- sound/pci/hda/hda_codec.c | 3 +++ 1 file changed, 3 insertions(+)
sound/pci/hda/hda_codec.c +3 -0
@@ -1608,8 +1608,11 @@ void snd_hda_ctls_clear(struct hda_codec *codec) {int i;struct hda_nid_item *items = codec->mixers.list; + +down_write (&codec->card->controls_rwsem);for (i =0 ; i < codec->mixers.used; i++)snd_ctl_remove (codec->card, items[i].kctl); +up_write (&codec->card->controls_rwsem);snd_array_free (&codec->mixers);snd_array_free (&codec->nids); }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 46/114 powerpc/prom_init: Fix improper check of prom_getprop()
In reply to Greg Kroah-HartmanFrom: Peiwei Hu <[email protected]>
[ Upstream commit 869fb7e5aecbc163003f93f36dcc26d0554319f6 ]
prom_getprop() can return PROM_ERROR. Binary operator can not identify it.
--- arch/powerpc/kernel/prom_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/kernel/prom_init.c +1 -1
@@ -2526,7 +2526,7 @@ static void __init fixup_device_tree_efika_add_phy(void)/* Check if the phy-handle property exists - bail if it does */ rv =prom_getprop (node,"phy-handle" , prop,sizeof (prop)); -if (!rv) +if (rv <=0 )return ;/*
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 47/114 ALSA: oss: fix compile error when OSS_DEBUG is enabled
In reply to Greg Kroah-HartmanFrom: Bixuan Cui <[email protected]>
[ Upstream commit 8e7daf318d97f25e18b2fc7eb5909e34cd903575 ]
Fix compile error when OSS_DEBUG is enabled:
sound/core/oss/pcm_oss.c: In function 'snd_pcm_oss_set_trigger':
sound/core/oss/pcm_oss.c:2055:10: error: 'substream' undeclared (first
use in this function); did you mean 'csubstream'?
pcm_dbg(substream->pcm, "pcm_oss: trigger = 0x%x\n", trigger);
^--- sound/core/oss/pcm_oss.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/core/oss/pcm_oss.c +1 -1
@@ -2121,7 +2121,7 @@ static int snd_pcm_oss_set_trigger(struct snd_pcm_oss_file *pcm_oss_file, int trint err, cmd;#ifdef OSS_DEBUG -pcm_dbg (substream->pcm,"pcm_oss: trigger = 0x%x\n" , trigger); +pr_debug ("pcm_oss: trigger = 0x%x\n" , trigger);#endif psubstream = pcm_oss_file->streams[SNDRV_PCM_STREAM_PLAYBACK ];
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 48/114 char/mwave: Adjust io port register size
In reply to Greg Kroah-HartmanFrom: Kees Cook <[email protected]>
[ Upstream commit f5912cc19acd7c24b2dbf65a6340bf194244f085 ]
Using MKWORD() on a byte-sized variable results in OOB read. Expand the size of the reserved area so both MKWORD and MKBYTE continue to work without overflow. Silences this warning on a -Warray-bounds build:
drivers/char/mwave/3780i.h:346:22: error: array subscript 'short unsigned int[0]' is partly outside array bounds of 'DSP_ISA_SLAVE_CONTROL[1]' [-Werror=array-bounds]
346 | #define MKWORD(var) (*((unsigned short *)(&var)))
| ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/char/mwave/3780i.h:356:40: note: in definition of macro 'OutWordDsp'
356 | #define OutWordDsp(index,value) outw(value,usDspBaseIO+index)
| ^~~~~drivers/char/mwave/3780i.c:373:41: note: in expansion of macro 'MKWORD'
373 | OutWordDsp(DSP_IsaSlaveControl, MKWORD(rSlaveControl));
| ^~~~~~drivers/char/mwave/3780i.c:358:31: note: while referencing 'rSlaveControl'
358 | DSP_ISA_SLAVE_CONTROL rSlaveControl;
| ^~~~~~~~~~~~~--- drivers/char/mwave/3780i.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/char/mwave/3780i.h +1 -1
@@ -68,7 +68,7 @@ typedef struct { unsigned char ClockControl:1; /* RW: Clock control: 0=normal, 1=stop 3780i clocks */ unsigned char SoftReset:1; /* RW: Soft reset 0=normal, 1=soft reset active */ unsigned char ConfigMode:1; /* RW: Configuration mode, 0=normal, 1=config mode */ - unsigned char Reserved:5; /* 0: Reserved */ + unsigned short Reserved:13; /* 0: Reserved */ }DSP_ISA_SLAVE_CONTROL ;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 49/114 uio: uio_dmem_genirq: Catch the Exception
In reply to Greg Kroah-HartmanFrom: Jiasheng Jiang <[email protected]>
[ Upstream commit eec91694f927d1026974444eb6a3adccd4f1cbc2 ]
The return value of dma_set_coherent_mask() is not always 0. To catch the exception in case that dma is not support the mask.
--- drivers/uio/uio_dmem_genirq.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/uio/uio_dmem_genirq.c +5 -1
@@ -194,7 +194,11 @@ static int uio_dmem_genirq_probe(struct platform_device *pdev) goto bad0; } -dma_set_coherent_mask (&pdev->dev,DMA_BIT_MASK (32 )); + ret =dma_set_coherent_mask (&pdev->dev,DMA_BIT_MASK (32 )); +if (ret) { +dev_err (&pdev->dev,"DMA enable failed\n" ); +return ret; + } priv->uioinfo = uioinfo;spin_lock_init (&priv->lock);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 50/114 RDMA/core: Let ib_find_gid() continue search even after empty entry
In reply to Greg Kroah-HartmanFrom: Avihai Horon <[email protected]>
[ Upstream commit 483d805191a23191f8294bbf9b4e94836f5d92e4 ]
Currently, ib_find_gid() will stop searching after encountering the first empty GID table entry. This behavior is wrong since neither IB nor RoCE spec enforce tightly packed GID tables.
For example, when a valid GID entry exists at index N, and if a GID entry is empty at index N-1, ib_find_gid() will fail to find the valid entry.
Fix it by making ib_find_gid() continue searching even after encountering missing entries.
--- drivers/infiniband/core/device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/infiniband/core/device.c +2 -1
@@ -848,7 +848,8 @@ int ib_find_gid(struct ib_device *device, union ib_gid *gid,for (i =0 ; i < device->port_immutable[port].gid_tbl_len; ++i) { ret =ib_query_gid (device, port, i, &tmp_gid,NULL );if (ret) -return ret; +continue ; +if (!memcmp (&tmp_gid, gid,sizeof *gid)) { *port_num = port;if (index)
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 51/114 dmaengine: pxa/mmp: stop referencing config->slave_id
In reply to Greg Kroah-HartmanFrom: Arnd Bergmann <[email protected]>
[ Upstream commit 134c37fa250a87a7e77c80a7c59ae16c462e46e0 ]
The last driver referencing the slave_id on Marvell PXA and MMP platforms was the SPI driver, but this stopped doing so a long time ago, so the TODO from the earlier patch can no be removed.
--- drivers/dma/mmp_pdma.c | 6 ------ drivers/dma/pxa_dma.c | 7 ------- 2 files changed, 13 deletions(-)
drivers/dma/mmp_pdma.c +0 -6
@@ -723,12 +723,6 @@ static int mmp_pdma_config(struct dma_chan *dchan, chan->dir = cfg->direction; chan->dev_addr = addr; -/* FIXME: drivers should be ported over to use the filter -* function. Once that's done, the following two lines can -* be removed. -*/ -if (cfg->slave_id) - chan->drcmr = cfg->slave_id;return 0 ; }
drivers/dma/pxa_dma.c +0 -7
@@ -959,13 +959,6 @@ static void pxad_get_config(struct pxad_chan *chan, *dcmd |=PXA_DCMD_BURST16 ; else if (maxburst == 32) *dcmd |= PXA_DCMD_BURST32; - - /* FIXME: drivers should be ported over to use the filter - * function. Once that's done, the following two lines can - * be removed. - */ - if (chan->cfg.slave_id) - chan->drcmr = chan->cfg.slave_id; } static struct dma_async_tx_descriptor *
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 52/114 ASoC: samsung: idma: Check of ioremap return value
In reply to Greg Kroah-HartmanFrom: Jiasheng Jiang <[email protected]>
[ Upstream commit 3ecb46755eb85456b459a1a9f952c52986bce8ec ]
Because of the potential failure of the ioremap(), the buf->area could be NULL.
Therefore, we need to check it and return -ENOMEM in order to transfer the error.
--- sound/soc/samsung/idma.c | 2 ++ 1 file changed, 2 insertions(+)
sound/soc/samsung/idma.c +2 -0
@@ -370,6 +370,8 @@ static int preallocate_idma_buffer(struct snd_pcm *pcm, int stream) buf->addr = idma.lp_tx_addr; buf->bytes = idma_hardware.buffer_bytes_max; buf->area = (unsigned char *__force )ioremap (buf->addr, buf->bytes); +if (!buf->area) +return -ENOMEM ;return 0 ; }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 53/114 misc: lattice-ecp3-config: Fix task hung when firmware load failed
In reply to Greg Kroah-HartmanFrom: Wei Yongjun <[email protected]>
[ Upstream commit fcee5ce50bdb21116711e38635e3865594af907e ]
When firmware load failed, kernel report task hung as follows:
INFO: task xrun:5191 blocked for more than 147 seconds.
Tainted: G W 5.16.0-rc5-next-20211220+ #11
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:xrun state:D stack: 0 pid: 5191 ppid: 270 flags:0x00000004
Call Trace:
__schedule+0xc12/0x4b50 kernel/sched/core.c:4986
schedule+0xd7/0x260 kernel/sched/core.c:6369 (discriminator 1)
schedule_timeout+0x7aa/0xa80 kernel/time/timer.c:1857
wait_for_completion+0x181/0x290 kernel/sched/completion.c:85
lattice_ecp3_remove+0x32/0x40 drivers/misc/lattice-ecp3-config.c:221
spi_remove+0x72/0xb0 drivers/spi/spi.c:409lattice_ecp3_remove() wait for signals from firmware loading, but when load failed, firmware_load() does not send this signal. This cause device remove hung. Fix it by sending signal even if load failed.
--- drivers/misc/lattice-ecp3-config.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/misc/lattice-ecp3-config.c +6 -6
@@ -81,12 +81,12 @@ static void firmware_load(const struct firmware *fw, void *context)if (fw ==NULL ) {dev_err (&spi->dev,"Cannot load firmware, aborting\n" ); -return ; + goto out; }if (fw->size ==0 ) {dev_err (&spi->dev,"Error: Firmware size is 0!\n" ); -return ; + goto out; }/* Fill dummy data (24 stuffing bits for commands) */
@@ -108,7 +108,7 @@ static void firmware_load(const struct firmware *fw, void *context)dev_err (&spi->dev,"Error: No supported FPGA detected (JEDEC_ID=%08x)!\n" , jedec_id); -return ; + goto out; }dev_info (&spi->dev,"FPGA %s detected\n" , ecp3_dev[i].name);
@@ -121,7 +121,7 @@ static void firmware_load(const struct firmware *fw, void *context) buffer =kzalloc (fw->size +8 ,GFP_KERNEL );if (!buffer) {dev_err (&spi->dev,"Error: Can't allocate memory!\n" ); -return ; + goto out; }/*
@@ -160,7 +160,7 @@ static void firmware_load(const struct firmware *fw, void *context)"Error: Timeout waiting for FPGA to clear (status=%08x)!\n" , status);kfree (buffer); -return ; + goto out; }dev_info (&spi->dev,"Configuring the FPGA...\n" );
@@ -186,7 +186,7 @@ static void firmware_load(const struct firmware *fw, void *context)release_firmware (fw);kfree (buffer); - +out:complete (&data->fw_loaded); }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 54/114 mips: lantiq: add support for clk_set_parent()
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit 76f66dfd60dc5d2f9dec22d99091fea1035c5d03 ]
Provide a simple implementation of clk_set_parent() in the lantiq subarch so that callers of it will build without errors.
Fixes these build errors:
ERROR: modpost: "clk_set_parent" [sound/soc/jz4740/snd-soc-jz4740-i2s.ko] undefined!
ERROR: modpost: "clk_set_parent" [sound/soc/atmel/snd-soc-atmel-i2s.ko] undefined!
[email protected] --cc="John Crispin <[email protected]>" --cc="Jonathan Cameron <[email protected]>" --cc="Russell King <[email protected]>" --cc="Andy Shevchenko <[email protected]>" [email protected] --to="Thomas Bogendoerfer <[email protected]>"
--- arch/mips/lantiq/clk.c | 6 ++++++ 1 file changed, 6 insertions(+)
arch/mips/lantiq/clk.c +6 -0
@@ -165,6 +165,12 @@ struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)return NULL ; } +int clk_set_parent (struct clk *clk,struct clk *parent) +{ +return 0 ; +} +EXPORT_SYMBOL (clk_set_parent); +static inline u32 get_counter_resolution (void ) {u32 res;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 55/114 mips: bcm63xx: add support for clk_set_parent()
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit 6f03055d508ff4feb8db02ba3df9303a1db8d381 ]
The MIPS BMC63XX subarch does not provide/support clk_set_parent(). This causes build errors in a few drivers, so add a simple implementation of that function so that callers of it will build without errors.
Fixes these build errors:
ERROR: modpost: "clk_set_parent" [sound/soc/jz4740/snd-soc-jz4740-i2s.ko] undefined!
ERROR: modpost: "clk_set_parent" [sound/soc/atmel/snd-soc-atmel-i2s.ko] undefined!
--- arch/mips/bcm63xx/clk.c | 6 ++++++ 1 file changed, 6 insertions(+)
arch/mips/bcm63xx/clk.c +6 -0
@@ -339,6 +339,12 @@ struct clk *clk_get_parent(struct clk *clk) }EXPORT_SYMBOL (clk_get_parent); +int clk_set_parent (struct clk *clk,struct clk *parent) +{ +return 0 ; +} +EXPORT_SYMBOL (clk_set_parent); +unsigned long clk_get_rate (struct clk *clk) {return clk->rate;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 56/114 RDMA/cxgb4: Set queue pair state when being queried
In reply to Greg Kroah-HartmanFrom: Kamal Heib <[email protected]>
[ Upstream commit e375b9c92985e409c4bb95dd43d34915ea7f5e28 ]
The API for ib_query_qp requires the driver to set cur_qp_state on return, add the missing set.
--- drivers/infiniband/hw/cxgb4/qp.c | 1 + 1 file changed, 1 insertion(+)
drivers/infiniband/hw/cxgb4/qp.c +1 -0
@@ -1896,6 +1896,7 @@ int c4iw_ib_query_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr,memset (attr,0 ,sizeof *attr);memset (init_attr,0 ,sizeof *init_attr); attr->qp_state =to_ib_qp_state (qhp->attr.state); + attr->cur_qp_state =to_ib_qp_state (qhp->attr.state); init_attr->cap.max_send_wr = qhp->attr.sq_num_entries; init_attr->cap.max_recv_wr = qhp->attr.rq_num_entries; init_attr->cap.max_send_sge = qhp->attr.sq_max_sges;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 57/114 Bluetooth: Fix debugfs entry leak in hci_register_dev()
In reply to Greg Kroah-HartmanFrom: Wei Yongjun <[email protected]>
[ Upstream commit 5a4bb6a8e981d3d0d492aa38412ee80b21033177 ]
Fault injection test report debugfs entry leak as follows:
debugfs: Directory 'hci0' with parent 'bluetooth' already present!
When register_pm_notifier() failed in hci_register_dev(), the debugfs create by debugfs_create_dir() do not removed in the error handing path.
Add the remove debugfs code to fix it.
--- net/bluetooth/hci_core.c | 1 + 1 file changed, 1 insertion(+)
net/bluetooth/hci_core.c +1 -0
@@ -3459,6 +3459,7 @@ int hci_register_dev(struct hci_dev *hdev)return id; err_wqueue: +debugfs_remove_recursive (hdev->debugfs);destroy_workqueue (hdev->workqueue);destroy_workqueue (hdev->req_workqueue); err:
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 58/114 fs: dlm: filter user dlm messages for kernel locks
In reply to Greg Kroah-HartmanFrom: Alexander Aring <[email protected]>
[ Upstream commit 6c2e3bf68f3e5e5a647aa52be246d5f552d7496d ]
This patch fixes the following crash by receiving a invalid message:
[ 160.672220] ================================================================== [ 160.676206] BUG: KASAN: user-memory-access in dlm_user_add_ast+0xc3/0x370 [ 160.679659] Read of size 8 at addr 00000000deadbeef by task kworker/u32:13/319 [ 160.681447] [ 160.681824] CPU: 10 PID: 319 Comm: kworker/u32:13 Not tainted 5.14.0-rc2+ #399 [ 160.683472] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.14.0-1.module+el8.6.0+12648+6ede71a5 04/01/2014 [ 160.685574] Workqueue: dlm_recv process_recv_sockets [ 160.686721] Call Trace: [ 160.687310] dump_stack_lvl+0x56/0x6f [ 160.688169] ? dlm_user_add_ast+0xc3/0x370 [ 160.689116] kasan_report.cold.14+0x116/0x11b [ 160.690138] ? dlm_user_add_ast+0xc3/0x370 [ 160.690832] dlm_user_add_ast+0xc3/0x370 [ 160.691502] _receive_unlock_reply+0x103/0x170 [ 160.692241] _receive_message+0x11df/0x1ec0 [ 160.692926] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 160.693700] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 160.694427] ? lock_acquire+0x175/0x400 [ 160.695058] ? do_purge.isra.51+0x200/0x200 [ 160.695744] ? lock_acquired+0x360/0x5d0 [ 160.696400] ? lock_contended+0x6a0/0x6a0 [ 160.697055] ? lock_release+0x21d/0x5e0 [ 160.697686] ? lock_is_held_type+0xe0/0x110 [ 160.698352] ? lock_is_held_type+0xe0/0x110 [ 160.699026] ? ___might_sleep+0x1cc/0x1e0 [ 160.699698] ? dlm_wait_requestqueue+0x94/0x140 [ 160.700451] ? dlm_process_requestqueue+0x240/0x240 [ 160.701249] ? down_write_killable+0x2b0/0x2b0 [ 160.701988] ? do_raw_spin_unlock+0xa2/0x130 [ 160.702690] dlm_receive_buffer+0x1a5/0x210 [ 160.703385] dlm_process_incoming_buffer+0x726/0x9f0 [ 160.704210] receive_from_sock+0x1c0/0x3b0 [ 160.704886] ? dlm_tcp_shutdown+0x30/0x30 [ 160.705561] ? lock_acquire+0x175/0x400 [ 160.706197] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 160.706941] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 160.707681] process_recv_sockets+0x32/0x40 [ 160.708366] process_one_work+0x55e/0xad0 [ 160.709045] ? pwq_dec_nr_in_flight+0x110/0x110 [ 160.709820] worker_thread+0x65/0x5e0 [ 160.710423] ? process_one_work+0xad0/0xad0 [ 160.711087] kthread+0x1ed/0x220 [ 160.711628] ? set_kthread_struct+0x80/0x80 [ 160.712314] ret_from_fork+0x22/0x30
The issue is that we received a DLM message for a user lock but the destination lock is a kernel lock. Note that the address which is trying to derefence is 00000000deadbeef, which is in a kernel lock lkb->lkb_astparam, this field should never be derefenced by the DLM kernel stack. In case of a user lock lkb->lkb_astparam is lkb->lkb_ua (memory is shared by a union field). The struct lkb_ua will be handled by the DLM kernel stack but on a kernel lock it will contain invalid data and ends in most likely crashing the kernel.
It can be reproduced with two cluster nodes.
node 2:dlm_tool join test
echo "862 fooobaar 1 2 1" > /sys/kernel/debug/dlm/test_locks echo "862 3 1" > /sys/kernel/debug/dlm/test_waiters
node 1:dlm_tool join test
python:
foo = DLM(h_cmd=3, o_nextcmd=1, h_nodeid=1, h_lockspace=0x77222027, \
m_type=7, m_flags=0x1, m_remid=0x862, m_result=0xFFFEFFFE)newFile = open("/sys/kernel/debug/dlm/comms/2/rawmsg", "wb") newFile.write(bytes(foo))
--- fs/dlm/lock.c | 9 +++++++++ 1 file changed, 9 insertions(+)
fs/dlm/lock.c +9 -0
@@ -3975,6 +3975,14 @@ static int validate_message(struct dlm_lkb *lkb, struct dlm_message *ms)int from = ms->m_header.h_nodeid;int error =0 ; +/* currently mixing of user/kernel locks are not supported */ +if (ms->m_flags &DLM_IFL_USER && ~lkb->lkb_flags &DLM_IFL_USER ) { +log_error (lkb->lkb_resource->res_ls, +"got user dlm message for a kernel lock" ); + error = -EINVAL ; + goto out; + } +switch (ms->m_type) {case DLM_MSG_CONVERT :case DLM_MSG_UNLOCK :
@@ -4003,6 +4011,7 @@ static int validate_message(struct dlm_lkb *lkb, struct dlm_message *ms) error = -EINVAL ; } +out:if (error) log_error(lkb->lkb_resource->res_ls, "ignore invalid message %d from %d %x %x %x %d",
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 59/114 ar5523: Fix null-ptr-deref with unexpected WDCMSG_TARGET_START reply
In reply to Greg Kroah-HartmanFrom: Zekun Shen <[email protected]>
[ Upstream commit ae80b6033834342601e99f74f6a62ff5092b1cee ]
Unexpected WDCMSG_TARGET_START replay can lead to null-ptr-deref when ar->tx_cmd->odata is NULL. The patch adds a null check to prevent such case.
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] ar5523_cmd+0x46a/0x581 [ar5523] ar5523_probe.cold+0x1b7/0x18da [ar5523] ? ar5523_cmd_rx_cb+0x7a0/0x7a0 [ar5523] ? __pm_runtime_set_status+0x54a/0x8f0 ? _raw_spin_trylock_bh+0x120/0x120 ? pm_runtime_barrier+0x220/0x220 ? __pm_runtime_resume+0xb1/0xf0 usb_probe_interface+0x25b/0x710 really_probe+0x209/0x5d0 driver_probe_device+0xc6/0x1b0 device_driver_attach+0xe2/0x120
I found the bug using a custome USBFuzz port. It's a research work to fuzz USB stack/drivers. I modified it to fuzz ath9k driver only, providing hand-crafted usb descriptors to QEMU.
After fixing the code (fourth byte in usb packet) to WDCMSG_TARGET_START, I got the null-ptr-deref bug. I believe the bug is triggerable whenever cmd->odata is NULL. After patching, I tested with the same input and no longer see the KASAN report.
This was NOT tested on a real device.
--- drivers/net/wireless/ath/ar5523/ar5523.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/wireless/ath/ar5523/ar5523.c +4 -0
@@ -153,6 +153,10 @@ static void ar5523_cmd_rx_cb(struct urb *urb)ar5523_err (ar,"Invalid reply to WDCMSG_TARGET_START" );return ; } +if (!cmd->odata) { +ar5523_err (ar,"Unexpected WDCMSG_TARGET_START reply" ); +return ; + }memcpy (cmd->odata, hdr +1 ,sizeof (u32)); cmd->olen =sizeof (u32); cmd->res =0 ;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 60/114 usb: gadget: f_fs: Use stream_open() for endpoint files
In reply to Greg Kroah-HartmanFrom: Pavankumar Kondeti <[email protected]>
[ Upstream commit c76ef96fc00eb398c8fc836b0eb2f82bcc619dc7 ]
Function fs endpoint file operations are synchronized via an interruptible mutex wait. However we see threads that do ep file operations concurrently are getting blocked for the mutex lock in __fdget_pos(). This is an uninterruptible wait and we see hung task warnings and kernel panic if hung_task_panic systcl is enabled if host does not send/receive the data for long time.
The reason for threads getting blocked in __fdget_pos() is due to the file position protection introduced by the commit 9c225f2655e3 ("vfs: atomic f_pos accesses as per POSIX"). Since function fs endpoint files does not have the notion of the file position, switch to the stream mode. This will bypass the file position mutex and threads will be blocked in interruptible state for the function fs mutex.
It should not affects user space as we are only changing the task state changes the task state from UNINTERRUPTIBLE to INTERRUPTIBLE while waiting for the USB transfers to be finished. However there is a slight change to the O_NONBLOCK behavior. Earlier threads that are using O_NONBLOCK are also getting blocked inside fdget_pos(). Now they reach to function fs and error code is returned. The non blocking behavior is actually honoured now.
--- drivers/usb/gadget/function/f_fs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/gadget/function/f_fs.c +2 -2
@@ -541,7 +541,7 @@ static int ffs_ep0_open(struct inode *inode, struct file *file) file->private_data = ffs;ffs_data_opened (ffs); -return 0 ; +return stream_open (inode, file); }static int ffs_ep0_release (struct inode *inode,struct file *file)
@@ -882,7 +882,7 @@ ffs_epfile_open(struct inode *inode, struct file *file) file->private_data = epfile;ffs_data_opened (epfile->ffs); -return 0 ; +return stream_open (inode, file); }static int ffs_aio_cancel (struct kiocb *kiocb)
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 61/114 media: b2c2: Add missing check in flexcop_pci_isr:
In reply to Greg Kroah-HartmanFrom: Zheyu Ma <[email protected]>
[ Upstream commit b13203032e679674c7c518f52a7ec0801ca3a829 ]
A out-of-bounds bug can be triggered by an interrupt, the reason for this bug is the lack of checking of register values.
In flexcop_pci_isr, the driver reads value from a register and uses it as a dma address. Finally, this address will be passed to the count parameter of find_next_packet. If this value is larger than the size of dma, the index of buffer will be out-of-bounds.
Fix this by adding a check after reading the value of the register.
The following KASAN report reveals it:
BUG: KASAN: slab-out-of-bounds in find_next_packet drivers/media/dvb-core/dvb_demux.c:528 [inline] BUG: KASAN: slab-out-of-bounds in _dvb_dmx_swfilter drivers/media/dvb-core/dvb_demux.c:572 [inline] BUG: KASAN: slab-out-of-bounds in dvb_dmx_swfilter+0x3fa/0x420 drivers/media/dvb-core/dvb_demux.c:603 Read of size 1 at addr ffff8880608c00a0 by task swapper/2/0 CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xec/0x156 lib/dump_stack.c:118 print_address_description+0x78/0x290 mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report+0x25b/0x380 mm/kasan/report.c:412 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:430 find_next_packet drivers/media/dvb-core/dvb_demux.c:528 [inline] _dvb_dmx_swfilter drivers/media/dvb-core/dvb_demux.c:572 [inline] dvb_dmx_swfilter+0x3fa/0x420 drivers/media/dvb-core/dvb_demux.c:603 flexcop_pass_dmx_data+0x2e/0x40 drivers/media/common/b2c2/flexcop.c:167 flexcop_pci_isr+0x3d1/0x5d0 drivers/media/pci/b2c2/flexcop-pci.c:212 __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149 handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206 handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725 generic_handle_irq_desc include/linux/irqdesc.h:155 [inline] handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670 </IRQ> RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61 Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 62 2f 8c 48 89 e5 e8 fb 31
e8 f8 8b 05 75 4f 8e 03 85 c0 7e 07 0f 00 2d 8a 61 66 00 fb f4 <5d> c3 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41
RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
RAX: 0000000000000000 RBX: ffffffff8bde44c8 RCX: ffffffff88a11285
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2f6200
RBP: ffff88806b71fcc8 R08: fffffbfff185ec40 R09: fffffbfff185ec40
R10: 0000000000000001 R11: fffffbfff185ec40 R12: 0000000000000002
R13: ffffffff8be9d6e0 R14: 0000000000000000 R15: 0000000000000000
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0x6f/0x360 arch/x86/kernel/process.c:557 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548 default_idle_call+0x3b/0x60 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369 start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 Allocated by task 1: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x11/0x20 mm/kasan/kasan.c:490 slab_post_alloc_hook mm/slab.h:445 [inline] slab_alloc_node mm/slub.c:2741 [inline] slab_alloc mm/slub.c:2749 [inline] kmem_cache_alloc+0xeb/0x280 mm/slub.c:2754 kmem_cache_zalloc include/linux/slab.h:699 [inline] __kernfs_new_node+0xe2/0x6f0 fs/kernfs/dir.c:633 kernfs_new_node+0x9a/0x120 fs/kernfs/dir.c:693 __kernfs_create_file+0x5f/0x340 fs/kernfs/file.c:992 sysfs_add_file_mode_ns+0x22a/0x4e0 fs/sysfs/file.c:306 create_files fs/sysfs/group.c:63 [inline] internal_create_group+0x34e/0xc30 fs/sysfs/group.c:147 sysfs_create_group fs/sysfs/group.c:173 [inline] sysfs_create_groups+0x9c/0x140 fs/sysfs/group.c:200 driver_add_groups+0x3e/0x50 drivers/base/driver.c:129 bus_add_driver+0x3a5/0x790 drivers/base/bus.c:684 driver_register+0x1cd/0x410 drivers/base/driver.c:170 __pci_register_driver+0x197/0x200 drivers/pci/pci-driver.c:1411 cx88_audio_pci_driver_init+0x23/0x25 drivers/media/pci/cx88/cx88-alsa.c: 1017 do_one_initcall+0xe0/0x610 init/main.c:884 do_initcall_level init/main.c:952 [inline] do_initcalls init/main.c:960 [inline] do_basic_setup init/main.c:978 [inline] kernel_init_freeable+0x4d0/0x592 init/main.c:1145 kernel_init+0x18/0x190 init/main.c:1062 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Freed by task 0:
(stack is not available)
The buggy address belongs to the object at ffff8880608c0000
which belongs to the cache kernfs_node_cache of size 160
The buggy address is located 0 bytes to the right of
160-byte region [ffff8880608c0000, ffff8880608c00a0)
The buggy address belongs to the page:
page:ffffea0001823000 count:1 mapcount:0 mapping:ffff88806bed1e00
index:0x0 compound_mapcount: 0
flags: 0x100000000008100(slab|head)
raw: 0100000000008100 dead000000000100 dead000000000200 ffff88806bed1e00
raw: 0000000000000000 0000000000240024 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880608bff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8880608c0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff8880608c0080: 00 00 00 00 fc fc fc fc fc fc fc fc 00 00 00 00
^
ffff8880608c0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8880608c0180: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
==================================================================--- drivers/media/pci/b2c2/flexcop-pci.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/media/pci/b2c2/flexcop-pci.c +3 -0
@@ -184,6 +184,8 @@ static irqreturn_t flexcop_pci_isr(int irq, void *dev_id)dma_addr_t cur_addr = fc->read_ibi_reg (fc,dma1_008).dma_0x8.dma_cur_addr <<2 ;u32 cur_pos = cur_addr - fc_pci->dma[0 ].dma_addr0; +if (cur_pos > fc_pci->dma[0 ].size *2 ) + goto error; deb_irq("%u irq: %08x cur_addr: %llx: cur_pos: %08x, " "last_cur_pos: %08x ",
@@ -225,6 +227,7 @@ static irqreturn_t flexcop_pci_isr(int irq, void *dev_id) ret =IRQ_NONE ; } +error:spin_unlock_irqrestore (&fc_pci->irq_lock, flags);return ret; }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 62/114 HSI: core: Fix return freed object in hsi_new_client
In reply to Greg Kroah-HartmanFrom: Chengfeng Ye <[email protected]>
[ Upstream commit a1ee1c08fcd5af03187dcd41dcab12fd5b379555 ]
cl is freed on error of calling device_register, but this object is return later, which will cause uaf issue. Fix it by return NULL on error.
--- drivers/hsi/hsi.c | 1 + 1 file changed, 1 insertion(+)
drivers/hsi/hsi.c +1 -0
@@ -115,6 +115,7 @@ struct hsi_client *hsi_new_client(struct hsi_port *port,if (device_register (&cl->device) <0 ) {pr_err ("hsi: failed to register client: %s\n" , info->name);put_device (&cl->device); + goto err; }return cl;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 63/114 mwifiex: Fix skb_over_panic in mwifiex_usb_recv()
In reply to Greg Kroah-HartmanFrom: Zekun Shen <[email protected]>
[ Upstream commit 04d80663f67ccef893061b49ec8a42ff7045ae84 ]
Currently, with an unknown recv_type, mwifiex_usb_recv just return -1 without restoring the skb. Next time mwifiex_usb_rx_complete is invoked with the same skb, calling skb_put causes skb_over_panic.
The bug is triggerable with a compromised/malfunctioning usb device. After applying the patch, skb_over_panic no longer shows up with the same input.
Attached is the panic report from fuzzing.
skbuff: skb_over_panic: text:000000003bf1b5fa
len:2048 put:4 head:00000000dd6a115b data:000000000a9445d8 tail:0x844 end:0x840 dev:<NULL>
kernel BUG at net/core/skbuff.c:109!
invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 0 PID: 198 Comm: in:imklog Not tainted 5.6.0 #60 RIP: 0010:skb_panic+0x15f/0x161 Call Trace: <IRQ> ? mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] skb_put.cold+0x24/0x24 mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] __usb_hcd_giveback_urb+0x1e4/0x380 usb_giveback_urb_bh+0x241/0x4f0 ? __hrtimer_run_queues+0x316/0x740 ? __usb_hcd_giveback_urb+0x380/0x380 tasklet_action_common.isra.0+0x135/0x330 __do_softirq+0x18c/0x634 irq_exit+0x114/0x140 smp_apic_timer_interrupt+0xde/0x380 apic_timer_interrupt+0xf/0x20 </IRQ>
--- drivers/net/wireless/mwifiex/usb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/wireless/mwifiex/usb.c +2 -1
@@ -132,7 +132,8 @@ static int mwifiex_usb_recv(struct mwifiex_adapter *adapter,default :mwifiex_dbg (adapter,ERROR ,"unknown recv_type %#x\n" , recv_type); -return -1 ; + ret =-1 ; + goto exit_restore_skb; }break ;case MWIFIEX_USB_EP_DATA :
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 64/114 floppy: Add max size check for user space request
In reply to Greg Kroah-HartmanFrom: Xiongwei Song <[email protected]>
[ Upstream commit 545a32498c536ee152331cd2e7d2416aa0f20e01 ]
We need to check the max request size that is from user space before allocating pages. If the request size exceeds the limit, return -EINVAL. This check can avoid the warning below from page allocator.
WARNING: CPU: 3 PID: 16525 at mm/page_alloc.c:5344 current_gfp_context include/linux/sched/mm.h:195 [inline] WARNING: CPU: 3 PID: 16525 at mm/page_alloc.c:5344 __alloc_pages+0x45d/0x500 mm/page_alloc.c:5356 Modules linked in: CPU: 3 PID: 16525 Comm: syz-executor.3 Not tainted 5.15.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 RIP: 0010:__alloc_pages+0x45d/0x500 mm/page_alloc.c:5344 Code: be c9 00 00 00 48 c7 c7 20 4a 97 89 c6 05 62 32 a7 0b 01 e8 74 9a 42 07 e9 6a ff ff ff 0f 0b e9 a0 fd ff ff 40 80 e5 3f eb 88 <0f> 0b e9 18 ff ff ff 4c 89 ef 44 89 e6 45 31 ed e8 1e 76 ff ff e9 RSP: 0018:ffffc90023b87850 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff92004770f0b RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000033 RDI: 0000000000010cc1 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff81bb4686 R11: 0000000000000001 R12: ffffffff902c1960 R13: 0000000000000033 R14: 0000000000000000 R15: ffff88804cf64a30 FS: 0000000000000000(0000) GS:ffff88802cd00000(0063) knlGS:00000000f44b4b40 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 000000002c921000 CR3: 000000004f507000 CR4: 0000000000150ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> alloc_pages+0x1a7/0x300 mm/mempolicy.c:2191 __get_free_pages+0x8/0x40 mm/page_alloc.c:5418 raw_cmd_copyin drivers/block/floppy.c:3113 [inline] raw_cmd_ioctl drivers/block/floppy.c:3160 [inline] fd_locked_ioctl+0x12e5/0x2820 drivers/block/floppy.c:3528 fd_ioctl drivers/block/floppy.c:3555 [inline] fd_compat_ioctl+0x891/0x1b60 drivers/block/floppy.c:3869 compat_blkdev_ioctl+0x3b8/0x810 block/ioctl.c:662 __do_compat_sys_ioctl+0x1c7/0x290 fs/ioctl.c:972 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x2f/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
--- drivers/block/floppy.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/block/floppy.c +3 -1
@@ -3116,6 +3116,8 @@ static void raw_cmd_free(struct floppy_raw_cmd **ptr) } } +#define MAX_LEN (1UL << MAX_ORDER << PAGE_SHIFT) +static int raw_cmd_copyin (int cmd,void __user *param,struct floppy_raw_cmd **rcmd) {
@@ -3153,7 +3155,7 @@ loop: ptr->resultcode =0 ;if (ptr->flags & (FD_RAW_READ |FD_RAW_WRITE )) { -if (ptr->length <=0 ) +if (ptr->length <=0 || ptr->length >=MAX_LEN )return -EINVAL ; ptr->kernel_data = (char *)fd_dma_mem_alloc (ptr->length);fallback_on_nodma_alloc (&ptr->kernel_data, ptr->length);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 65/114 media: saa7146: hexium_orion: Fix a NULL pointer dereference in hexium_attach()
In reply to Greg Kroah-HartmanFrom: Zhou Qingyang <[email protected]>
[ Upstream commit 348df8035301dd212e3cc2860efe4c86cb0d3303 ]
In hexium_attach(dev, info), saa7146_vv_init() is called to allocate a new memory for dev->vv_data. In hexium_detach(), saa7146_vv_release() will be called and there is a dereference of dev->vv_data in saa7146_vv_release(), which could lead to a NULL pointer dereference on failure of saa7146_vv_init() according to the following logic.
Both hexium_attach() and hexium_detach() are callback functions of the variable 'extension', so there exists a possible call chain directly from hexium_attach() to hexium_detach():
hexium_attach(dev, info) -- fail to alloc memory to dev->vv_data
| in saa7146_vv_init(). | |
hexium_detach() -- a dereference of dev->vv_data in saa7146_vv_release()
Fix this bug by adding a check of saa7146_vv_init().
This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug.
Builds with CONFIG_VIDEO_HEXIUM_ORION=m show no new warnings, and our static analyzer no longer warns about this code.
--- drivers/media/pci/saa7146/hexium_orion.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/media/pci/saa7146/hexium_orion.c +7 -1
@@ -366,10 +366,16 @@ static struct saa7146_ext_vv vv_data;static int hexium_attach (struct saa7146_dev *dev,struct saa7146_pci_extension_data *info) {struct hexium *hexium = (struct hexium *) dev->ext_priv; +int ret;DEB_EE ("\n" ); -saa7146_vv_init (dev, &vv_data); + ret =saa7146_vv_init (dev, &vv_data); +if (ret) { +pr_err ("Error in saa7146_vv_init()\n" ); +return ret; + } + vv_data.vid_ops.vidioc_enum_input = vidioc_enum_input; vv_data.vid_ops.vidioc_g_input = vidioc_g_input; vv_data.vid_ops.vidioc_s_input = vidioc_s_input;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 66/114 media: m920x: dont use stack on USB reads
In reply to Greg Kroah-HartmanFrom: Mauro Carvalho Chehab <[email protected]>
[ Upstream commit a2ab06d7c4d6bfd0b545a768247a70463e977e27 ]
Using stack-allocated pointers for USB message data don't work. This driver is almost OK with that, except for the I2C read logic.
Fix it by using a temporary read buffer, just like on all other calls to m920x_read().
--- drivers/media/usb/dvb-usb/m920x.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
drivers/media/usb/dvb-usb/m920x.c +11 -1
@@ -284,6 +284,13 @@ static int m920x_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[], int nu/* Should check for ack here, if we knew how. */ }if (msg[i].flags &I2C_M_RD ) { +char *read =kmalloc (1 ,GFP_KERNEL ); +if (!read) { + ret = -ENOMEM ; +kfree (read); + goto unlock; + } +for (j =0 ; j < msg[i].len; j++) {/* Last byte of transaction? * Send STOP, otherwise send ACK. */
@@ -291,9 +298,12 @@ static int m920x_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[], int nuif ((ret =m920x_read (d->udev,M9206_I2C ,0x0 ,0x20 | stop, - &msg[i].buf[j],1 )) !=0 ) + read,1 )) !=0 ) goto unlock; + msg[i].buf[j] = read[0 ]; } + +kfree (read); }else {for (j =0 ; j < msg[i].len; j++) {/* Last byte of transaction? Then send STOP. */
Signature · 1 line
2.34.1
Re: [PATCH 4.4 066/114] media: m920x: dont use stack on USB reads
Hi!
Quoted 10 lines
From: Mauro Carvalho Chehab <[email protected]>
[ Upstream commit
a2ab06d7c4d6bfd0b545a768247a70463e977e27]Using stack-allocated pointers for USB message data don't work. This driver is almost OK with that, except for the I2C read logic.
Fix it by using a temporary read buffer, just like on all other calls to
m920x_read().
Maybe the driver is buggy, but the fix is not okay.
Review static int m920x_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[], int nu · line 290
Quoted 9 lines
+++
b/drivers/media/usb/dvb-usb/m920x.c(quoted diff) +4
-0@@ -284,6 +284,13 @@ static int m920x_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[], int nu /* Should check for ack here, if we knew how. */ } if (msg[i].flags & I2C_M_RD) { + char *read = kmalloc(1, GFP_KERNEL); + if (!read) { + ret = -ENOMEM; + kfree(read);
kfree(NULL). You probably did not want to do that.
Review static int m920x_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[], int nu · line 302
Quoted 13 lines
(quoted diff) +4
-1+ goto unlock; + } + for (j = 0; j < msg[i].len; j++) { /* Last byte of transaction? * Send STOP, otherwise send ACK. */@@ -291,9 +298,12 @@ static int m920x_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[], int nu if ((ret = m920x_read(d->udev, M9206_I2C, 0x0, 0x20 | stop, - &msg[i].buf[j], 1)) != 0) + read, 1)) != 0) goto unlock;
Memory leak here.
Review static int m920x_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[], int nu · line 309
Quoted 7 lines
(quoted diff) +3
-0+ msg[i].buf[j] = read[0]; } + + kfree(read); } else { for (j = 0; j < msg[i].len; j++) { /* Last byte of transaction? Then send STOP. */
Plus really running malloc in a loop like that looks strange.
Anyway, this should stop the leaks.
Best regards,
Pavel
drivers/media/usb/dvb-usb/m920x.c +3 -2
@@ -277,7 +277,6 @@ static int m920x_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[], int nuchar *read =kmalloc (1 ,GFP_KERNEL );if (!read) { ret = -ENOMEM ; -kfree (read); goto unlock; }
@@ -288,8 +287,10 @@ static int m920x_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[], int nuif ((ret =m920x_read (d->udev,M9206_I2C ,0x0 ,0x20 | stop, - read,1 )) !=0 ) + read,1 )) !=0 ) { +kfree (read); goto unlock; + } msg[i].buf[j] = read[0 ]; }
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Greg Kroah-Hartman
maintainerPATCH 67/114 iwlwifi: mvm: synchronize with FW after multicast commands
In reply to Greg Kroah-HartmanFrom: Johannes Berg <[email protected]>
[ Upstream commit db66abeea3aefed481391ecc564fb7b7fb31d742 ]
If userspace installs a lot of multicast groups very quickly, then we may run out of command queue space as we send the updates in an asynchronous fashion (due to locking concerns), and the CPU can create them faster than the firmware can process them. This is true even when mac80211 has a work struct that gets scheduled.
Fix this by synchronizing with the firmware after sending all those commands - outside of the iteration we can send a synchronous echo command that just has the effect of the CPU waiting for the prior asynchronous commands to finish. This also will cause fewer of the commands to be sent to the firmware overall, because the work will only run once when rescheduled multiple times while it's running.
--- drivers/net/wireless/iwlwifi/mvm/mac80211.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
drivers/net/wireless/iwlwifi/mvm/mac80211.c +17 -0
@@ -1957,6 +1957,7 @@ static void iwl_mvm_recalc_multicast(struct iwl_mvm *mvm)struct iwl_mvm_mc_iter_data iter_data = { .mvm = mvm, }; +int ret;lockdep_assert_held (&mvm->mutex);
@@ -1966,6 +1967,22 @@ static void iwl_mvm_recalc_multicast(struct iwl_mvm *mvm)ieee80211_iterate_active_interfaces_atomic ( mvm->hw,IEEE80211_IFACE_ITER_NORMAL , iwl_mvm_mc_iface_iterator, &iter_data); + +/* +* Send a (synchronous) ech command so that we wait for the +* multiple asynchronous MCAST_FILTER_CMD commands sent by +* the interface iterator. Otherwise, we might get here over +* and over again (by userspace just sending a lot of these) +* and the CPU can send them faster than the firmware can +* process them. +* Note that the CPU is still faster - but with this we'll +* actually send fewer commands overall because the CPU will +* not schedule the work in mac80211 as frequently if it's +* still running when rescheduled (possibly multiple times). +*/ + ret =iwl_mvm_send_cmd_pdu (mvm,ECHO_CMD ,0 ,0 ,NULL ); +if (ret) +IWL_ERR (mvm,"Failed to synchronize multicast groups update\n" ); } static u64 iwl_mvm_prepare_multicast(struct ieee80211_hw *hw,
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 68/114 net: bonding: debug: avoid printing debug logs when bond is not notifying peers
In reply to Greg Kroah-HartmanFrom: Suresh Kumar <[email protected]>
[ Upstream commit fee32de284ac277ba434a2d59f8ce46528ff3946 ]
Currently "bond_should_notify_peers: slave ..." messages are printed whenever "bond_should_notify_peers" function is called.
+++
Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: (slave enp0s25): Received LACPDU on port 1 Dec 12 12:33:26 node1 kernel: bond0: (slave enp0s25): Rx Machine: Port=1, Last State=6, Curr State=6 Dec 12 12:33:26 node1 kernel: bond0: (slave enp0s25): partner sync=1 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 ... Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:30 node1 kernel: bond0: (slave enp4s3): Received LACPDU on port 2 Dec 12 12:33:30 node1 kernel: bond0: (slave enp4s3): Rx Machine: Port=2, Last State=6, Curr State=6 Dec 12 12:33:30 node1 kernel: bond0: (slave enp4s3): partner sync=1 Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25 Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25
+++
This is confusing and can also clutter up debug logs. Print logs only when the peer notification happens.
--- drivers/net/bonding/bond_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/bonding/bond_main.c +3 -3
@@ -785,14 +785,14 @@ static bool bond_should_notify_peers(struct bonding *bond) slave =rcu_dereference (bond->curr_active_slave);rcu_read_unlock (); -netdev_dbg (bond->dev,"bond_should_notify_peers: slave %s\n" , - slave ? slave->dev->name :"NULL" ); -if (!slave || !bond->send_peer_notif || !netif_carrier_ok (bond->dev) ||test_bit (__LINK_STATE_LINKWATCH_PENDING, &slave->dev->state))return false; +netdev_dbg (bond->dev,"bond_should_notify_peers: slave %s\n" , + slave ? slave->dev->name :"NULL" ); +return true; }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 69/114 media: igorplugusb: receiver overflow should be reported
In reply to Greg Kroah-HartmanFrom: Sean Young <[email protected]>
[ Upstream commit 8fede658e7ddb605bbd68ed38067ddb0af033db4 ]
Without this, some IR will be missing mid-stream and we might decode something which never really occurred.
--- drivers/media/rc/igorplugusb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/media/rc/igorplugusb.c +3 -1
@@ -73,9 +73,11 @@ static void igorplugusb_irdata(struct igorplugusb *ir, unsigned len)if (start >= len) {dev_err (ir->dev,"receive overflow invalid: %u" , overflow); }else { -if (overflow >0 ) +if (overflow >0 ) {dev_warn (ir->dev,"receive overflow, at least %u lost" , overflow); +ir_raw_event_reset (ir->rc); + } do { rawir.duration = ir->buf_in[i] * 85333;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 70/114 media: saa7146: hexium_gemini: Fix a NULL pointer dereference in hexium_attach()
In reply to Greg Kroah-HartmanFrom: Zhou Qingyang <[email protected]>
[ Upstream commit 3af86b046933ba513d08399dba0d4d8b50d607d0 ]
In hexium_attach(dev, info), saa7146_vv_init() is called to allocate a new memory for dev->vv_data. saa7146_vv_release() will be called on failure of saa7146_register_device(). There is a dereference of dev->vv_data in saa7146_vv_release(), which could lead to a NULL pointer dereference on failure of saa7146_vv_init().
Fix this bug by adding a check of saa7146_vv_init().
This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug.
Builds with CONFIG_VIDEO_HEXIUM_GEMINI=m show no new warnings, and our static analyzer no longer warns about this code.
--- drivers/media/common/saa7146/saa7146_fops.c | 2 +- drivers/media/pci/saa7146/hexium_gemini.c | 7 ++++++- 2 files changed, 7 insertions(+), 2 deletions(-)
drivers/media/common/saa7146/saa7146_fops.c +1 -1
@@ -524,7 +524,7 @@ int saa7146_vv_init(struct saa7146_dev* dev, struct saa7146_ext_vv *ext_vv)ERR ("out of memory. aborting.\n" );kfree (vv);v4l2_ctrl_handler_free (hdl); -return -1 ; +return -ENOMEM ; } saa7146_video_uops.init (dev,vv);
drivers/media/pci/saa7146/hexium_gemini.c +6 -1
@@ -296,7 +296,12 @@ static int hexium_attach(struct saa7146_dev *dev, struct saa7146_pci_extension_dhexium_set_input (hexium,0 ); hexium->cur_input =0 ; -saa7146_vv_init (dev, &vv_data); + ret =saa7146_vv_init (dev, &vv_data); +if (ret) { +i2c_del_adapter (&hexium->i2c_adapter); +kfree (hexium); +return ret; + } vv_data.vid_ops.vidioc_enum_input = vidioc_enum_input; vv_data.vid_ops.vidioc_g_input = vidioc_g_input;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 71/114 usb: hub: Add delay for SuperSpeed hub resume to let links transit to U0
In reply to Greg Kroah-HartmanFrom: Kai-Heng Feng <[email protected]>
[ Upstream commit 00558586382891540c59c9febc671062425a6e47 ]
When a new USB device gets plugged to nested hubs, the affected hub, which connects to usb 2-1.4-port2, doesn't report there's any change, hence the nested hubs go back to runtime suspend like nothing happened:
[ 281.032951] usb usb2: usb wakeup-resume [ 281.032959] usb usb2: usb auto-resume [ 281.032974] hub 2-0:1.0: hub_resume [ 281.033011] usb usb2-port1: status 0263 change 0000 [ 281.033077] hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0000 [ 281.049797] usb 2-1: usb wakeup-resume [ 281.069800] usb 2-1: Waited 0ms for CONNECT [ 281.069810] usb 2-1: finish resume [ 281.070026] hub 2-1:1.0: hub_resume [ 281.070250] usb 2-1-port4: status 0203 change 0000 [ 281.070272] usb usb2-port1: resume, status 0 [ 281.070282] hub 2-1:1.0: state 7 ports 4 chg 0010 evt 0000 [ 281.089813] usb 2-1.4: usb wakeup-resume [ 281.109792] usb 2-1.4: Waited 0ms for CONNECT [ 281.109801] usb 2-1.4: finish resume [ 281.109991] hub 2-1.4:1.0: hub_resume [ 281.110147] usb 2-1.4-port2: status 0263 change 0000 [ 281.110234] usb 2-1-port4: resume, status 0 [ 281.110239] usb 2-1-port4: status 0203, change 0000, 10.0 Gb/s [ 281.110266] hub 2-1.4:1.0: state 7 ports 4 chg 0000 evt 0000 [ 281.110426] hub 2-1.4:1.0: hub_suspend [ 281.110565] usb 2-1.4: usb auto-suspend, wakeup 1 [ 281.130998] hub 2-1:1.0: hub_suspend [ 281.137788] usb 2-1: usb auto-suspend, wakeup 1 [ 281.142935] hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0000 [ 281.177828] usb 2-1: usb wakeup-resume [ 281.197839] usb 2-1: Waited 0ms for CONNECT [ 281.197850] usb 2-1: finish resume [ 281.197984] hub 2-1:1.0: hub_resume [ 281.198203] usb 2-1-port4: status 0203 change 0000 [ 281.198228] usb usb2-port1: resume, status 0 [ 281.198237] hub 2-1:1.0: state 7 ports 4 chg 0010 evt 0000 [ 281.217835] usb 2-1.4: usb wakeup-resume [ 281.237834] usb 2-1.4: Waited 0ms for CONNECT [ 281.237845] usb 2-1.4: finish resume [ 281.237990] hub 2-1.4:1.0: hub_resume [ 281.238067] usb 2-1.4-port2: status 0263 change 0000 [ 281.238148] usb 2-1-port4: resume, status 0 [ 281.238152] usb 2-1-port4: status 0203, change 0000, 10.0 Gb/s [ 281.238166] hub 2-1.4:1.0: state 7 ports 4 chg 0000 evt 0000 [ 281.238385] hub 2-1.4:1.0: hub_suspend [ 281.238523] usb 2-1.4: usb auto-suspend, wakeup 1 [ 281.258076] hub 2-1:1.0: hub_suspend [ 281.265744] usb 2-1: usb auto-suspend, wakeup 1 [ 281.285976] hub 2-0:1.0: hub_suspend [ 281.285988] usb usb2: bus auto-suspend, wakeup 1
USB 3.2 spec, 9.2.5.4 "Changing Function Suspend State" says that "If the link is in a non-U0 state, then the device must transition the link to U0 prior to sending the remote wake message", but the hub only transits the link to U0 after signaling remote wakeup.
So be more forgiving and use a 20ms delay to let the link transit to U0 for remote wakeup.
--- drivers/usb/core/hub.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/usb/core/hub.c +4 -1
@@ -1054,7 +1054,10 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) }else {hub_power_on (hub, true); } - } +/* Give some time on remote wakeup to let links to transit to U0 */ + }else if (hub_is_superspeed (hub->hdev)) +msleep (20 ); + init2:/*
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 72/114 ath9k: Fix out-of-bound memcpy in ath9k_hif_usb_rx_stream
In reply to Greg Kroah-HartmanFrom: Zekun Shen <[email protected]>
[ Upstream commit 6ce708f54cc8d73beca213cec66ede5ce100a781 ]
Large pkt_len can lead to out-out-bound memcpy. Current ath9k_hif_usb_rx_stream allows combining the content of two urb inputs to one pkt. The first input can indicate the size of the pkt. Any remaining size is saved in hif_dev->rx_remain_len. While processing the next input, memcpy is used with rx_remain_len.
4-byte pkt_len can go up to 0xffff, while a single input is 0x4000 maximum in size (MAX_RX_BUF_SIZE). Thus, the patch adds a check for pkt_len which must not exceed 2 * MAX_RX_BUG_SIZE.
BUG: KASAN: slab-out-of-bounds in ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] Read of size 46393 at addr ffff888018798000 by task kworker/0:1/23 CPU: 0 PID: 23 Comm: kworker/0:1 Not tainted 5.6.0 #63 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: <IRQ> dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] ? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] __kasan_report.cold+0x37/0x7c ? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] kasan_report+0xe/0x20 check_memory_region+0x15a/0x1d0 memcpy+0x20/0x50 ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc] ? hif_usb_mgmt_cb+0x2d9/0x2d9 [ath9k_htc] ? _raw_spin_lock_irqsave+0x7b/0xd0 ? _raw_spin_trylock_bh+0x120/0x120 ? __usb_unanchor_urb+0x12f/0x210 __usb_hcd_giveback_urb+0x1e4/0x380 usb_giveback_urb_bh+0x241/0x4f0 ? __hrtimer_run_queues+0x316/0x740 ? __usb_hcd_giveback_urb+0x380/0x380 tasklet_action_common.isra.0+0x135/0x330 __do_softirq+0x18c/0x634 irq_exit+0x114/0x140 smp_apic_timer_interrupt+0xde/0x380 apic_timer_interrupt+0xf/0x20
I found the bug using a custome USBFuzz port. It's a research work to fuzz USB stack/drivers. I modified it to fuzz ath9k driver only, providing hand-crafted usb descriptors to QEMU.
After fixing the value of pkt_tag to ATH_USB_RX_STREAM_MODE_TAG in QEMU emulation, I found the KASAN report. The bug is triggerable whenever pkt_len is above two MAX_RX_BUG_SIZE. I used the same input that crashes to test the driver works when applying the patch.
--- drivers/net/wireless/ath/ath9k/hif_usb.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/net/wireless/ath/ath9k/hif_usb.c +7 -0
@@ -586,6 +586,13 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev,return ; } +if (pkt_len >2 *MAX_RX_BUF_SIZE ) { +dev_err (&hif_dev->udev->dev, +"ath9k_htc: invalid pkt_len (%x)\n" , pkt_len); +RX_STAT_INC (skb_dropped); +return ; + } + pad_len =4 - (pkt_len &0x3 );if (pad_len ==4 ) pad_len =0 ;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 73/114 um: registers: Rename function names to avoid conflicts and build problems
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit 077b7320942b64b0da182aefd83c374462a65535 ]
The function names init_registers() and restore_registers() are used in several net/ethernet/ and gpu/drm/ drivers for other purposes (not calls to UML functions), so rename them.
This fixes multiple build errors.
--- arch/um/include/shared/registers.h | 4 ++-- arch/um/os-Linux/registers.c | 4 ++-- arch/um/os-Linux/start_up.c | 2 +- arch/x86/um/syscalls_64.c | 3 ++- 4 files changed, 7 insertions(+), 6 deletions(-)
arch/um/include/shared/registers.h +2 -2
@@ -14,8 +14,8 @@ extern int restore_fp_registers(int pid, unsigned long *fp_regs);extern int save_fpx_registers (int pid,unsigned long *fp_regs);extern int restore_fpx_registers (int pid,unsigned long *fp_regs);extern int save_registers (int pid,struct uml_pt_regs *regs); -extern int restore_registers (int pid,struct uml_pt_regs *regs); -extern int init_registers (int pid); +extern int restore_pid_registers (int pid,struct uml_pt_regs *regs); +extern int init_pid_registers (int pid);extern void get_safe_registers (unsigned long *regs,unsigned long *fp_regs);extern unsigned long get_thread_reg (int reg,jmp_buf *buf);extern int get_fp_registers (int pid,unsigned long *regs);
arch/um/os-Linux/registers.c +2 -2
@@ -21,7 +21,7 @@ int save_registers(int pid, struct uml_pt_regs *regs)return 0 ; } -int restore_registers (int pid,struct uml_pt_regs *regs) +int restore_pid_registers (int pid,struct uml_pt_regs *regs) {int err;
@@ -36,7 +36,7 @@ int restore_registers(int pid, struct uml_pt_regs *regs)static unsigned long exec_regs[MAX_REG_NR ];static unsigned long exec_fp_regs[FP_SIZE ]; -int init_registers (int pid) +int init_pid_registers (int pid) {int err;
arch/um/os-Linux/start_up.c +1 -1
@@ -334,7 +334,7 @@ void __init os_early_checks(void)check_tmpexec (); pid =start_ptraced_child (); -if (init_registers (pid)) +if (init_pid_registers (pid))fatal ("Failed to initialize default registers" );stop_ptraced_child (pid,1 ,1 ); }
arch/x86/um/syscalls_64.c +2 -1
@@ -9,6 +9,7 @@#include <linux/uaccess.h> #include <asm/prctl.h> /* XXX This should get the constants from libc */ #include <os.h> +#include <registers.h> long arch_prctl (struct task_struct *task,int code,unsigned long __user *addr) {
@@ -32,7 +33,7 @@ long arch_prctl(struct task_struct *task, int code, unsigned long __user *addr)switch (code) {case ARCH_SET_FS :case ARCH_SET_GS : - ret =restore_registers (pid, ¤t->thread.regs.regs); + ret =restore_pid_registers (pid, ¤t->thread.regs.regs);if (ret)return ret;break ;
Signature · 9 lines
2.34.1 _______________________________________________ linux-um mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-um
Greg Kroah-Hartman
maintainerPATCH 74/114 ACPICA: Utilities: Avoid deleting the same object twice in a row
In reply to Greg Kroah-HartmanFrom: Rafael J. Wysocki <[email protected]>
[ Upstream commit 1cdfe9e346b4c5509ffe19ccde880fd259d9f7a3 ]
ACPICA commit c11af67d8f7e3d381068ce7771322f2b5324d687
If original_count is 0 in acpi_ut_update_ref_count (), acpi_ut_delete_internal_obj () is invoked for the target object, which is incorrect, because that object has been deleted once already and the memory allocated to store it may have been reclaimed and allocated for a different purpose by the host OS. Moreover, a confusing debug message following the "Reference Count is already zero, cannot decrement" warning is printed in that case.
To fix this issue, make acpi_ut_update_ref_count () return after finding that original_count is 0 and printing the above warning.
--- drivers/acpi/acpica/utdelete.c | 1 + 1 file changed, 1 insertion(+)
drivers/acpi/acpica/utdelete.c +1 -0
@@ -439,6 +439,7 @@ acpi_ut_update_ref_count(union acpi_operand_object *object, u32 action)ACPI_WARNING ((AE_INFO ,"Obj %p, Reference Count is already zero, cannot decrement\n" , object)); +return ; } ACPI_DEBUG_PRINT((ACPI_DB_ALLOCATIONS,
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 75/114 ACPICA: Executer: Fix the REFCLASS_REFOF case in acpi_ex_opcode_1A_0T_1R()
In reply to Greg Kroah-HartmanFrom: Rafael J. Wysocki <[email protected]>
[ Upstream commit 24ea5f90ec9548044a6209685c5010edd66ffe8f ]
ACPICA commit d984f12041392fa4156b52e2f7e5c5e7bc38ad9e
If Operand[0] is a reference of the ACPI_REFCLASS_REFOF class, acpi_ex_opcode_1A_0T_1R () calls acpi_ns_get_attached_object () to obtain return_desc which may require additional resolution with the help of acpi_ex_read_data_from_field (). If the latter fails, the reference counter of the original return_desc is decremented which is incorrect, because acpi_ns_get_attached_object () does not increment the reference counter of the object returned by it.
This issue may lead to premature deletion of the attached object while it is still attached and a use-after-free and crash in the host OS. For example, this may happen when on evaluation of ref_of() a local region field where there is no registered handler for the given Operation Region.
Fix it by making acpi_ex_opcode_1A_0T_1R () return Status right away after a acpi_ex_read_data_from_field () failure.
--- drivers/acpi/acpica/exoparg1.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/acpi/acpica/exoparg1.c +2 -1
@@ -1016,7 +1016,8 @@ acpi_status acpi_ex_opcode_1A_0T_1R(struct acpi_walk_state *walk_state) (walk_state, return_desc, &temp_desc);if (ACPI_FAILURE (status)) { - goto cleanup; +return_ACPI_STATUS + (status); } return_desc = temp_desc;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 76/114 btrfs: remove BUG_ON() in find_parent_nodes()
In reply to Greg Kroah-HartmanFrom: Josef Bacik <[email protected]>
[ Upstream commit fcba0120edf88328524a4878d1d6f4ad39f2ec81 ]
We search for an extent entry with .offset = -1, which shouldn't be a thing, but corruption happens. Add an ASSERT() for the developers, return -EUCLEAN for mortals.
--- fs/btrfs/backref.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
fs/btrfs/backref.c +6 -1
@@ -975,7 +975,12 @@ again: ret =btrfs_search_slot (trans, fs_info->extent_root, &key, path,0 ,0 );if (ret <0 ) goto out; -BUG_ON (ret ==0 ); +if (ret ==0 ) { +/* This shouldn't happen, indicates a bug or fs corruption. */ +ASSERT (ret !=0 ); + ret = -EUCLEAN ; + goto out; + }#ifdef CONFIG_BTRFS_FS_RUN_SANITY_TESTS if (trans && likely(trans->type != __TRANS_DUMMY) &&
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 77/114 btrfs: remove BUG_ON(!eie) in find_parent_nodes
In reply to Greg Kroah-HartmanFrom: Josef Bacik <[email protected]>
[ Upstream commit 9f05c09d6baef789726346397438cca4ec43c3ee ]
If we're looking for leafs that point to a data extent we want to record the extent items that point at our bytenr. At this point we have the reference and we know for a fact that this leaf should have a reference to our bytenr. However if there's some sort of corruption we may not find any references to our leaf, and thus could end up with eie == NULL. Replace this BUG_ON() with an ASSERT() and then return -EUCLEAN for the mortals.
--- fs/btrfs/backref.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
fs/btrfs/backref.c +11 -3
@@ -1109,10 +1109,18 @@ again: goto out;if (!ret && extent_item_pos) {/* -* we've recorded that parent, so we must extend -* its inode list here +* We've recorded that parent, so we must extend +* its inode list here. +* +* However if there was corruption we may not +* have found an eie, return an error in this +* case. */ -BUG_ON (!eie); +ASSERT (eie); +if (!eie) { + ret = -EUCLEAN ; + goto out; + }while (eie->next) eie = eie->next; eie->next = ref->inode_list;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 78/114 net: mdio: Demote probed message to debug print
In reply to Greg Kroah-HartmanFrom: Florian Fainelli <[email protected]>
[ Upstream commit 7590fc6f80ac2cbf23e6b42b668bbeded070850b ]
On systems with large numbers of MDIO bus/muxes the message indicating that a given MDIO bus has been successfully probed is repeated for as many buses we have, which can eat up substantial boot time for no reason, demote to a debug print.
--- drivers/net/phy/mdio_bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/phy/mdio_bus.c +1 -1
@@ -295,7 +295,7 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner) } bus->state =MDIOBUS_REGISTERED ; -pr_info ("%s: probed\n" , bus->name); +dev_dbg (&bus->dev,"probed\n" );return 0 ; error:
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 79/114 dm btree: add a defensive bounds check to insert_at()
In reply to Greg Kroah-HartmanFrom: Joe Thornber <[email protected]>
[ Upstream commit 85bca3c05b6cca31625437eedf2060e846c4bbad ]
Corrupt metadata could trigger an out of bounds write.
--- drivers/md/persistent-data/dm-btree.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/md/persistent-data/dm-btree.c +5 -3
@@ -83,14 +83,16 @@ void inc_children(struct dm_transaction_manager *tm, struct btree_node *n, }static int insert_at (size_t value_size,struct btree_node *node,unsigned index, -uint64_t key,void *value) -__dm_written_to_disk (value) +uint64_t key,void *value) +__dm_written_to_disk (value) {uint32_t nr_entries =le32_to_cpu (node->header.nr_entries); +uint32_t max_entries =le32_to_cpu (node->header.max_entries);__le64 key_le =cpu_to_le64 (key);if (index > nr_entries || - index >=le32_to_cpu (node->header.max_entries)) { + index >= max_entries || + nr_entries >= max_entries) {DMERR ("too many entries in btree node for insert" );__dm_unbless_for_disk (value);return -ENOMEM ;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 80/114 dm space map common: add bounds check to sm_ll_lookup_bitmap()
In reply to Greg Kroah-HartmanFrom: Joe Thornber <[email protected]>
[ Upstream commit cba23ac158db7f3cd48a923d6861bee2eb7a2978 ]
Corrupted metadata could warrant returning error from sm_ll_lookup_bitmap().
--- drivers/md/persistent-data/dm-space-map-common.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/md/persistent-data/dm-space-map-common.c +5 -0
@@ -279,6 +279,11 @@ int sm_ll_lookup_bitmap(struct ll_disk *ll, dm_block_t b, uint32_t *result)struct disk_index_entry ie_disk;struct dm_block *blk; +if (b >= ll->nr_blocks) { +DMERR_LIMIT ("metadata block out of bounds" ); +return -EINVAL ; + } + b =do_div (index, ll->entries_per_block); r = ll->load_ie (ll, index, &ie_disk);if (r <0 )
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 81/114 serial: pl010: Drop CR register reset on set_termios
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
[ Upstream commit 08a0c6dff91c965e39905cf200d22db989203ccb ]
pl010_set_termios() briefly resets the CR register to zero.
Where does this register write come from?
The PL010 driver's IRQ handler ambauart_int() originally modified the CR register without holding the port spinlock. ambauart_set_termios() also modified that register. To prevent concurrent read-modify-writes by the IRQ handler and to prevent transmission while changing baudrate, ambauart_set_termios() had to disable interrupts. That is achieved by writing zero to the CR register.
However in 2004 the PL010 driver was amended to acquire the port spinlock in the IRQ handler, obviating the need to disable interrupts in ->set_termios():
https://git.kernel.org/history/history/c/157c0342e591
That rendered the CR register write obsolete. Drop it.
--- drivers/tty/serial/amba-pl010.c | 3 --- 1 file changed, 3 deletions(-)
drivers/tty/serial/amba-pl010.c +0 -3
@@ -465,14 +465,11 @@ pl010_set_termios(struct uart_port *port, struct ktermios *termios,if ((termios->c_cflag &CREAD ) ==0 ) uap->port.ignore_status_mask |=UART_DUMMY_RSR_RX ; -/* first, disable everything */ old_cr =readb (uap->port.membase +UART010_CR ) & ~UART010_CR_MSIE ;if (UART_ENABLE_MS (port, termios->c_cflag)) old_cr |=UART010_CR_MSIE ; -writel (0 , uap->port.membase +UART010_CR ); -/* Set baud rate */ quot -=1 ;writel ((quot &0xf00 ) >>8 , uap->port.membase +UART010_LCRM );
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 82/114 serial: core: Keep mctrl register state and cached copy in sync
In reply to Greg Kroah-HartmanFrom: Lukas Wunner <[email protected]>
[ Upstream commit 93a770b7e16772530196674ffc79bb13fa927dc6 ]
struct uart_port contains a cached copy of the Modem Control signals. It is used to skip register writes in uart_update_mctrl() if the new signal state equals the old signal state. It also avoids a register read to obtain the current state of output signals.
When a uart_port is registered, uart_configure_port() changes signal state but neglects to keep the cached copy in sync. That may cause a subsequent register write to be incorrectly skipped. Fix it before it trips somebody up.
This behavior has been present ever since the serial core was introduced in 2002:
https://git.kernel.org/history/history/c/33c0d1b0c3eb
So far it was never an issue because the cached copy is initialized to 0 by kzalloc() and when uart_configure_port() is executed, at most DTR has been set by uart_set_options() or sunsu_console_setup(). Therefore, a stable designation seems unnecessary.
--- drivers/tty/serial/serial_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/tty/serial/serial_core.c +2 -1
@@ -2247,7 +2247,8 @@ uart_configure_port(struct uart_driver *drv, struct uart_state *state,* We probably don't need a spinlock around this, but */ spin_lock_irqsave (&port->lock, flags); - port->ops->set_mctrl (port, port->mctrl &TIOCM_DTR ); + port->mctrl &=TIOCM_DTR ; + port->ops->set_mctrl (port, port->mctrl);spin_unlock_irqrestore (&port->lock, flags);/*
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 83/114 parisc: Avoid calling faulthandler_disabled() twice
In reply to Greg Kroah-HartmanFrom: John David Anglin <[email protected]>
[ Upstream commit 9e9d4b460f23bab61672eae397417d03917d116c ]
In handle_interruption(), we call faulthandler_disabled() to check whether the fault handler is not disabled. If the fault handler is disabled, we immediately call do_page_fault(). It then calls faulthandler_disabled(). If disabled, do_page_fault() attempts to fixup the exception by jumping to no_context:
no_context:
if (!user_mode(regs) && fixup_exception(regs)) {
return;
}
parisc_terminate("Bad Address (null pointer deref?)", regs, code, address);Apart from the error messages, the two blocks of code perform the same function.
We can avoid two calls to faulthandler_disabled() by a simple revision to the code in handle_interruption().
Note: I didn't try to fix the formatting of this code block.
--- arch/parisc/kernel/traps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/parisc/kernel/traps.c +1 -1
@@ -796,7 +796,7 @@ void notrace handle_interruption(int code, struct pt_regs *regs)* unless pagefault_disable() was called before. */ -if (fault_space ==0 && !faulthandler_disabled ()) +if (faulthandler_disabled () || fault_space ==0 ) {/* Clean up and return if in exception table. */ if (fixup_exception (regs))
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 84/114 powerpc/6xx: add missing of_node_put
In reply to Greg Kroah-HartmanFrom: Julia Lawall <[email protected]>
[ Upstream commit f6e82647ff71d427d4148964b71f239fba9d7937 ]
for_each_compatible_node performs an of_node_get on each iteration, so a break out of the loop requires an of_node_put.
A simplified version of the semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr):
// <smpl>
@@
expression e;
local idexpression n;
@@
@@
local idexpression n;
expression e;
@@
for_each_compatible_node(n,...) {
...
(
of_node_put(n);
|
e = n
|
+ of_node_put(n);
? break;
)
...
}
... when != n
// </smpl>
--- arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 1 + 1 file changed, 1 insertion(+)
arch/powerpc/platforms/embedded6xx/hlwd-pic.c +1 -0
@@ -220,6 +220,7 @@ void hlwd_pic_probe(void)irq_set_chained_handler (cascade_virq, hlwd_pic_irq_cascade); hlwd_irq_host = host; +of_node_put (np);break ; } }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 85/114 powerpc/powernv: add missing of_node_put
In reply to Greg Kroah-HartmanFrom: Julia Lawall <[email protected]>
[ Upstream commit 7d405a939ca960162eb30c1475759cb2fdf38f8c ]
for_each_compatible_node performs an of_node_get on each iteration, so a break out of the loop requires an of_node_put.
A simplified version of the semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr):
// <smpl>
@@
local idexpression n;
expression e;
@@
for_each_compatible_node(n,...) {
...
(
of_node_put(n);
|
e = n
|
+ of_node_put(n);
? break;
)
...
}
... when != n
// </smpl>
--- arch/powerpc/platforms/powernv/opal-lpc.c | 1 + 1 file changed, 1 insertion(+)
arch/powerpc/platforms/powernv/opal-lpc.c +1 -0
@@ -401,6 +401,7 @@ void opal_lpc_init(void)if (!of_get_property (np,"primary" ,NULL ))continue ; opal_lpc_chip_id =of_get_ibm_chip_id (np); +of_node_put (np);break ; }if (opal_lpc_chip_id <0 )
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 86/114 powerpc/cell: add missing of_node_put
In reply to Greg Kroah-HartmanFrom: Julia Lawall <[email protected]>
[ Upstream commit a841fd009e51c8c0a8f07c942e9ab6bb48da8858 ]
for_each_node_by_name performs an of_node_get on each iteration, so a break out of the loop requires an of_node_put.
A simplified version of the semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr):
// <smpl>
@@
expression e,e1;
local idexpression n;
@@
for_each_node_by_name(n, e1) {
... when != of_node_put(n)
when != e = n
(
return n;
|
+ of_node_put(n);
? return ...;
)
...
}
// </smpl>
--- arch/powerpc/platforms/cell/iommu.c | 1 + 1 file changed, 1 insertion(+)
arch/powerpc/platforms/cell/iommu.c +1 -0
@@ -1107,6 +1107,7 @@ static int __init cell_iommu_fixed_mapping_init(void)if (hbase < dbase || (hend > (dbase + dsize))) {pr_debug ("iommu: hash window doesn't fit in" "real DMA window\n" ); +of_node_put (np);return -1 ; } }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 87/114 powerpc/btext: add missing of_node_put
In reply to Greg Kroah-HartmanFrom: Julia Lawall <[email protected]>
[ Upstream commit a1d2b210ffa52d60acabbf7b6af3ef7e1e69cda0 ]
for_each_node_by_type performs an of_node_get on each iteration, so a break out of the loop requires an of_node_put.
A simplified version of the semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr):
// <smpl>
@@
local idexpression n;
expression e;
@@
for_each_node_by_type(n,...) {
...
(
of_node_put(n);
|
e = n
|
+ of_node_put(n);
? break;
)
...
}
... when != n
// </smpl>
--- arch/powerpc/kernel/btext.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/powerpc/kernel/btext.c +3 -1
@@ -257,8 +257,10 @@ int __init btext_find_display(int allow_nonstdout) rc =btext_initialize (np);printk ("result: %d\n" , rc); } -if (rc ==0 ) +if (rc ==0 ) { +of_node_put (np);break ; + } }return rc; }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 88/114 i2c: i801: Dont silently correct invalid transfer size
In reply to Greg Kroah-HartmanFrom: Heiner Kallweit <[email protected]>
[ Upstream commit effa453168a7eeb8a562ff4edc1dbf9067360a61 ]
If an invalid block size is provided, reject it instead of silently changing it to a supported value. Especially critical I see the case of a write transfer with block length 0. In this case we have no guarantee that the byte we would write is valid. When silently reducing a read to 32 bytes then we don't return an error and the caller may falsely assume that we returned the full requested data.
If this change should break any (broken) caller, then I think we should fix the caller.
--- drivers/i2c/busses/i2c-i801.c | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-)
drivers/i2c/busses/i2c-i801.c +5 -10
@@ -669,6 +669,11 @@ static int i801_block_transaction(struct i801_priv *priv,int result =0 ;unsigned char hostc; +if (read_write ==I2C_SMBUS_READ && command ==I2C_SMBUS_BLOCK_DATA ) + data->block[0 ] =I2C_SMBUS_BLOCK_MAX ; +else if (data->block[0 ] <1 || data->block[0 ] >I2C_SMBUS_BLOCK_MAX ) +return -EPROTO ; +if (command ==I2C_SMBUS_I2C_BLOCK_DATA ) {if (read_write ==I2C_SMBUS_WRITE ) {/* set I2C_EN bit in configuration register */
@@ -682,16 +687,6 @@ static int i801_block_transaction(struct i801_priv *priv, } } -if (read_write ==I2C_SMBUS_WRITE - || command ==I2C_SMBUS_I2C_BLOCK_DATA ) { -if (data->block[0 ] <1 ) - data->block[0 ] =1 ; -if (data->block[0 ] >I2C_SMBUS_BLOCK_MAX ) - data->block[0 ] =I2C_SMBUS_BLOCK_MAX ; - }else { - data->block[0 ] =32 ;/* max for SMBus block reads */ - } -/* Experience has shown that the block buffer can only be used for SMBus (not I2C) block transactions, even though the datasheet doesn't mention this limitation. */
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 89/114 powerpc/smp: Move setup_profiling_timer() under CONFIG_PROFILING
In reply to Greg Kroah-HartmanFrom: Michael Ellerman <[email protected]>
[ Upstream commit a4ac0d249a5db80e79d573db9e4ad29354b643a8 ]
setup_profiling_timer() is only needed when CONFIG_PROFILING is enabled.
Fixes the following W=1 warning when CONFIG_PROFILING=n:
linux/arch/powerpc/kernel/smp.c:1638:5: error: no previous prototype for ‘setup_profiling_timer’
--- arch/powerpc/kernel/smp.c | 2 ++ 1 file changed, 2 insertions(+)
arch/powerpc/kernel/smp.c +2 -0
@@ -732,10 +732,12 @@ void start_secondary(void *unused)BUG (); } +#ifdef CONFIG_PROFILING int setup_profiling_timer (unsigned int multiplier) {return 0 ; } +#endif #ifdef CONFIG_SCHED_SMT /* cpumask of CPUs with asymetric SMT dependancy */
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 90/114 i2c: mpc: Correct I2C reset procedure
In reply to Greg Kroah-HartmanFrom: Joakim Tjernlund <[email protected]>
[ Upstream commit ebe82cf92cd4825c3029434cabfcd2f1780e64be ]
Current I2C reset procedure is broken in two ways:
1) It only generate 1 START instead of 9 STARTs and STOP.
2) It leaves the bus Busy so every I2C xfer after the first fixup calls the reset routine again, for every xfer there after.
This fixes both errors.
--- drivers/i2c/busses/i2c-mpc.c | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-)
drivers/i2c/busses/i2c-mpc.c +15 -8
@@ -107,23 +107,30 @@ static irqreturn_t mpc_i2c_isr(int irq, void *dev_id)/* Sometimes 9th clock pulse isn't generated, and slave doesn't release * the bus, because it wants to send ACK. * Following sequence of enabling/disabling and sending start/stop generates -* the 9 pulses, so it's all OK. +* the 9 pulses, each with a START then ending with STOP, so it's all OK. */ static void mpc_i2c_fixup (struct mpc_i2c *i2c) {int k; -u32 delay_val =1000000 / i2c->real_clk +1 ; - -if (delay_val <2 ) - delay_val =2 ; +unsigned long flags;for (k =9 ; k; k--) {writeccr (i2c,0 ); -writeccr (i2c,CCR_MSTA |CCR_MTX |CCR_MEN ); +writeb (0 , i2c->base +MPC_I2C_SR );/* clear any status bits */ +writeccr (i2c,CCR_MEN |CCR_MSTA );/* START */ +readb (i2c->base +MPC_I2C_DR );/* init xfer */ +udelay (15 );/* let it hit the bus */ +local_irq_save (flags);/* should not be delayed further */ +writeccr (i2c,CCR_MEN |CCR_MSTA |CCR_RSTA );/* delay SDA */ readb (i2c->base +MPC_I2C_DR ); -writeccr (i2c,CCR_MEN ); -udelay (delay_val <<1 ); +if (k !=1 ) +udelay (5 ); +local_irq_restore (flags); } +writeccr (i2c,CCR_MEN );/* Initiate STOP */ +readb (i2c->base +MPC_I2C_DR ); +udelay (15 );/* Let STOP propagate */ +writeccr (i2c,0 ); }static int i2c_wait (struct mpc_i2c *i2c,unsigned timeout,int writing)
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 91/114 w1: Misuse of get_user()/put_user() reported by sparse
In reply to Greg Kroah-HartmanFrom: Christophe Leroy <[email protected]>
[ Upstream commit 33dc3e3e99e626ce51f462d883b05856c6c30b1d ]
sparse warnings: (new ones prefixed by >>)
Quoted 1 line
Quoted 1 line
drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char [noderef]__user*_pu_addr@@ got char *buf @@
drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: expected char [noderef] __user *_pu_addr
drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: got char *buf
Quoted 1 line
Quoted 1 line
drivers/w1/slaves/w1_ds28e04.c:356:13: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected char const [noderef]__user*_gu_addr@@ got char const *buf @@
drivers/w1/slaves/w1_ds28e04.c:356:13: sparse: expected char const [noderef] __user *_gu_addr
drivers/w1/slaves/w1_ds28e04.c:356:13: sparse: got char const *buf
The buffer buf is a failsafe buffer in kernel space, it's not user memory hence doesn't deserve the use of get_user() or put_user().
Access 'buf' content directly.
--- drivers/w1/slaves/w1_ds28e04.c | 26 ++++++-------------------- 1 file changed, 6 insertions(+), 20 deletions(-)
drivers/w1/slaves/w1_ds28e04.c +6 -20
@@ -39,7 +39,7 @@ static int w1_strong_pullup = 1;module_param_named (strong_pullup, w1_strong_pullup, int,0 );/* enable/disable CRC checking on DS28E04-100 memory accesses */ -static char w1_enable_crccheck =1 ; +static bool w1_enable_crccheck = true;#define W1_EEPROM_SIZE 512#define W1_PAGE_COUNT 16
@@ -346,32 +346,18 @@ static BIN_ATTR_RW(pio, 1);static ssize_t crccheck_show (struct device *dev,struct device_attribute *attr,char *buf) { -if (put_user (w1_enable_crccheck +0x30 , buf)) -return -EFAULT ; - -return sizeof (w1_enable_crccheck); +return sysfs_emit (buf,"%d\n" , w1_enable_crccheck); }static ssize_t crccheck_store (struct device *dev,struct device_attribute *attr,const char *buf,size_t count) { -char val; - -if (count !=1 || !buf) -return -EINVAL ; +int err =kstrtobool (buf, &w1_enable_crccheck); -if (get_user (val, buf)) -return -EFAULT ; +if (err) +return err; -/* convert to decimal */ - val = val -0x30 ; -if (val !=0 && val !=1 ) -return -EINVAL ; - -/* set the new value */ - w1_enable_crccheck = val; - -return sizeof (w1_enable_crccheck); +return count; }static DEVICE_ATTR_RW (crccheck);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 92/114 ALSA: seq: Set upper limit of processed events
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
[ Upstream commit 6fadb494a638d8b8a55864ecc6ac58194f03f327 ]
Currently ALSA sequencer core tries to process the queued events as much as possible when they become dispatchable. If applications try to queue too massive events to be processed at the very same timing, the sequencer core would still try to process such all events, either in the interrupt context or via some notifier; in either away, it might be a cause of RCU stall or such problems.
As a potential workaround for those problems, this patch adds the upper limit of the amount of events to be processed. The remaining events are processed in the next batch, so they won't be lost.
For the time being, it's limited up to 1000 events per queue, which should be high enough for any normal usages.
--- sound/core/seq/seq_queue.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
sound/core/seq/seq_queue.c +12 -2
@@ -257,12 +257,15 @@ struct snd_seq_queue *snd_seq_queue_find_name(char *name)/* -------------------------------------------------------- */ +#define MAX_CELL_PROCESSES_IN_QUEUE 1000 +void snd_seq_check_queue (struct snd_seq_queue *q,int atomic,int hop) {unsigned long flags;struct snd_seq_event_cell *cell;snd_seq_tick_time_t cur_tick;snd_seq_real_time_t cur_time; +int processed =0 ;if (q ==NULL )return ;
@@ -285,6 +288,8 @@ void snd_seq_check_queue(struct snd_seq_queue *q, int atomic, int hop)if (!cell)break ;snd_seq_dispatch_event (cell, atomic, hop); +if (++processed >=MAX_CELL_PROCESSES_IN_QUEUE ) + goto out;/* the rest processed at the next batch */ }/* Process time queue... */
@@ -294,14 +299,19 @@ void snd_seq_check_queue(struct snd_seq_queue *q, int atomic, int hop)if (!cell)break ;snd_seq_dispatch_event (cell, atomic, hop); +if (++processed >=MAX_CELL_PROCESSES_IN_QUEUE ) + goto out;/* the rest processed at the next batch */ } + out:/* free lock */ spin_lock_irqsave (&q->check_lock, flags);if (q->check_again) { q->check_again =0 ; -spin_unlock_irqrestore (&q->check_lock, flags); - goto __again; +if (processed <MAX_CELL_PROCESSES_IN_QUEUE ) { +spin_unlock_irqrestore (&q->check_lock, flags); + goto __again; + } } q->check_blocked =0 ;spin_unlock_irqrestore (&q->check_lock, flags);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 93/114 i2c: designware-pci: Fix to change data types of hcnt and lcnt parameters
In reply to Greg Kroah-HartmanFrom: Lakshmi Sowjanya D <[email protected]>
[ Upstream commit d52097010078c1844348dc0e467305e5f90fd317 ]
The data type of hcnt and lcnt in the struct dw_i2c_dev is of type u16. It's better to have same data type in struct dw_scl_sda_cfg as well.
--- drivers/i2c/busses/i2c-designware-pcidrv.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/i2c/busses/i2c-designware-pcidrv.c +4 -4
@@ -53,10 +53,10 @@ enum dw_pci_ctl_id_t { };struct dw_scl_sda_cfg { -u32 ss_hcnt; -u32 fs_hcnt; -u32 ss_lcnt; -u32 fs_lcnt; +u16 ss_hcnt; +u16 fs_hcnt; +u16 ss_lcnt; +u16 fs_lcnt;u32 sda_hold; };
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 94/114 MIPS: Octeon: Fix build errors using clang
In reply to Greg Kroah-HartmanFrom: Tianjia Zhang <[email protected]>
[ Upstream commit 95339b70677dc6f9a2d669c4716058e71b8dc1c7 ]
A large number of the following errors is reported when compiling with clang:
cvmx-bootinfo.h:326:3: error: adding 'int' to a string does not append to the string [-Werror,-Wstring-plus-int]
ENUM_BRD_TYPE_CASE(CVMX_BOARD_TYPE_NULL)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cvmx-bootinfo.h:321:20: note: expanded from macro 'ENUM_BRD_TYPE_CASE'
case x: return(#x + 16); /* Skip CVMX_BOARD_TYPE_ */
~~~^~~~
cvmx-bootinfo.h:326:3: note: use array indexing to silence this warning
cvmx-bootinfo.h:321:20: note: expanded from macro 'ENUM_BRD_TYPE_CASE'
case x: return(#x + 16); /* Skip CVMX_BOARD_TYPE_ */
^Follow the prompts to use the address operator '&' to fix this error.
--- arch/mips/include/asm/octeon/cvmx-bootinfo.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/mips/include/asm/octeon/cvmx-bootinfo.h +2 -2
@@ -303,7 +303,7 @@ enum cvmx_chip_types_enum {/* Functions to return string based on type */ #define ENUM_BRD_TYPE_CASE (x) \ - case x: return(#x + 16);/* Skip CVMX_BOARD_TYPE_ */ + case x: return (&#x[16]);/* Skip CVMX_BOARD_TYPE_ */ static inline const char *cvmx_board_type_to_string (enum cvmx_board_types_enum type) {
@@ -392,7 +392,7 @@ static inline const char *cvmx_board_type_to_string(enum }#define ENUM_CHIP_TYPE_CASE (x) \ - case x: return(#x + 15);/* Skip CVMX_CHIP_TYPE */ + case x: return (&#x[15]);/* Skip CVMX_CHIP_TYPE */ static inline const char *cvmx_chip_type_to_string (enum cvmx_chip_types_enum type) {
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 95/114 scsi: sr: Dont use GFP_DMA
In reply to Greg Kroah-HartmanFrom: Christoph Hellwig <[email protected]>
[ Upstream commit d94d94969a4ba07a43d62429c60372320519c391 ]
The allocated buffers are used as a command payload, for which the block layer and/or DMA API do the proper bounce buffering if needed.
--- drivers/scsi/sr.c | 2 +- drivers/scsi/sr_vendor.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
drivers/scsi/sr.c +1 -1
@@ -883,7 +883,7 @@ static void get_capabilities(struct scsi_cd *cd)/* allocate transfer buffer */ - buffer =kmalloc (512 ,GFP_KERNEL |GFP_DMA ); + buffer =kmalloc (512 ,GFP_KERNEL );if (!buffer) {sr_printk (KERN_ERR , cd,"out of memory.\n" );return ;
drivers/scsi/sr_vendor.c +2 -2
@@ -118,7 +118,7 @@ int sr_set_blocklength(Scsi_CD *cd, int blocklength) density = (blocklength >2048 ) ?0x81 :0x83 ;#endif - buffer =kmalloc (512 ,GFP_KERNEL |GFP_DMA ); + buffer =kmalloc (512 ,GFP_KERNEL );if (!buffer)return -ENOMEM ;
@@ -166,7 +166,7 @@ int sr_cd_check(struct cdrom_device_info *cdi)if (cd->cdi.mask &CDC_MULTI_SESSION )return 0 ; - buffer =kmalloc (512 ,GFP_KERNEL |GFP_DMA ); + buffer =kmalloc (512 ,GFP_KERNEL );if (!buffer)return -ENOMEM ;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 96/114 power: bq25890: Enable continuous conversion for ADC at charging
In reply to Greg Kroah-HartmanFrom: Yauhen Kharuzhy <[email protected]>
[ Upstream commit 80211be1b9dec04cc2805d3d81e2091ecac289a1 ]
Instead of one shot run of ADC at beginning of charging, run continuous conversion to ensure that all charging-related values are monitored properly (input voltage, input current, themperature etc.).
--- drivers/power/bq25890_charger.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/power/bq25890_charger.c +2 -2
@@ -521,12 +521,12 @@ static void bq25890_handle_state_change(struct bq25890_device *bq,if (!new_state->online) {/* power removed */ /* disable ADC */ - ret =bq25890_field_write (bq,F_CONV_START ,0 ); + ret =bq25890_field_write (bq,F_CONV_RATE ,0 );if (ret <0 ) goto error; }else if (!old_state.online) {/* power inserted */ /* enable ADC, to have control of charge current/voltage */ - ret =bq25890_field_write (bq,F_CONV_START ,1 ); + ret =bq25890_field_write (bq,F_CONV_RATE ,1 );if (ret <0 ) goto error; }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 97/114 ubifs: Error path in ubifs_remount_rw() seems to wrongly free write buffers
In reply to Greg Kroah-HartmanFrom: Petr Cvachoucek <[email protected]>
commit 3fea4d9d160186617ff40490ae01f4f4f36b28ff upstream.
it seems freeing the write buffers in the error path of the ubifs_remount_rw() is wrong. It leads later to a kernel oops like this:
[10016.431274] UBIFS (ubi0:0): start fixing up free space [10090.810042] UBIFS (ubi0:0): free space fixup complete [10090.814623] UBIFS error (ubi0:0 pid 512): ubifs_remount_fs: cannot spawn "ubifs_bgt0_0", error -4 [10101.915108] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 517 [10105.275498] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [10105.284352] Mem abort info: [10105.287160] ESR = 0x96000006 [10105.290252] EC = 0x25: DABT (current EL), IL = 32 bits [10105.295592] SET = 0, FnV = 0 [10105.298652] EA = 0, S1PTW = 0 [10105.301848] Data abort info: [10105.304723] ISV = 0, ISS = 0x00000006 [10105.308573] CM = 0, WnR = 0 [10105.311564] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000f03d1000 [10105.318034] [0000000000000030] pgd=00000000f6cee003, pud=00000000f4884003, pmd=0000000000000000 [10105.326783] Internal error: Oops: 96000006 [#1] PREEMPT SMP [10105.332355] Modules linked in: ath10k_pci ath10k_core ath mac80211 libarc4 cfg80211 nvme nvme_core cryptodev(O) [10105.342468] CPU: 3 PID: 518 Comm: touch Tainted: G O 5.4.3 #1 [10105.349517] Hardware name: HYPEX CPU (DT) [10105.353525] pstate: 40000005 (nZcv daif -PAN -UAO) [10105.358324] pc : atomic64_try_cmpxchg_acquire.constprop.22+0x8/0x34 [10105.364596] lr : mutex_lock+0x1c/0x34 [10105.368253] sp : ffff000075633aa0 [10105.371563] x29: ffff000075633aa0 x28: 0000000000000001 [10105.376874] x27: ffff000076fa80c8 x26: 0000000000000004 [10105.382185] x25: 0000000000000030 x24: 0000000000000000 [10105.387495] x23: 0000000000000000 x22: 0000000000000038 [10105.392807] x21: 000000000000000c x20: ffff000076fa80c8 [10105.398119] x19: ffff000076fa8000 x18: 0000000000000000 [10105.403429] x17: 0000000000000000 x16: 0000000000000000 [10105.408741] x15: 0000000000000000 x14: fefefefefefefeff [10105.414052] x13: 0000000000000000 x12: 0000000000000fe0 [10105.419364] x11: 0000000000000fe0 x10: ffff000076709020 [10105.424675] x9 : 0000000000000000 x8 : 00000000000000a0 [10105.429986] x7 : ffff000076fa80f4 x6 : 0000000000000030 [10105.435297] x5 : 0000000000000000 x4 : 0000000000000000 [10105.440609] x3 : 0000000000000000 x2 : ffff00006f276040 [10105.445920] x1 : ffff000075633ab8 x0 : 0000000000000030 [10105.451232] Call trace: [10105.453676] atomic64_try_cmpxchg_acquire.constprop.22+0x8/0x34 [10105.459600] ubifs_garbage_collect+0xb4/0x334 [10105.463956] ubifs_budget_space+0x398/0x458 [10105.468139] ubifs_create+0x50/0x180 [10105.471712] path_openat+0x6a0/0x9b0 [10105.475284] do_filp_open+0x34/0x7c [10105.478771] do_sys_open+0x78/0xe4 [10105.482170] __arm64_sys_openat+0x1c/0x24 [10105.486180] el0_svc_handler+0x84/0xc8 [10105.489928] el0_svc+0x8/0xc [10105.492808] Code: 52800013 17fffffb d2800003 f9800011 (c85ffc05) [10105.498903] ---[ end trace 46b721d93267a586 ]---
To reproduce the problem:
1. Filesystem initially mounted read-only, free space fixup flag set.
2. mount -o remount,rw <mountpoint>
3. it takes some time (free space fixup running)
... try to terminate running mount by CTRL-C
... does not respond, only after free space fixup is complete ... then "ubifs_remount_fs: cannot spawn "ubifs_bgt0_0", error -4"
4. mount -o remount,rw <mountpoint>
... now finished instantly (fixup already done).
5. Create file or just unmount the filesystem and we get the oops.
--- fs/ubifs/super.c | 1 - 1 file changed, 1 deletion(-)
fs/ubifs/super.c +0 -1
@@ -1695,7 +1695,6 @@ out:kthread_stop (c->bgt); c->bgt =NULL ; } -free_wbufs (c);kfree (c->write_reserve_buf); c->write_reserve_buf =NULL ;vfree (c->ileb_buf);
Greg Kroah-Hartman
maintainerPATCH 98/114 ext4: set csum seed in tmp inode while migrating to extents
In reply to Greg Kroah-HartmanFrom: Luís Henriques <[email protected]>
commit e81c9302a6c3c008f5c30beb73b38adb0170ff2d upstream.
When migrating to extents, the temporary inode will have it's own checksum seed. This means that, when swapping the inodes data, the inode checksums will be incorrect.
This can be fixed by recalculating the extents checksums again. Or simply by copying the seed into the temporary inode.
--- fs/ext4/migrate.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
fs/ext4/migrate.c +11 -1
@@ -481,6 +481,17 @@ int ext4_ext_migrate(struct inode *inodeext4_journal_stop (handle);return retval; } +/* +* Use the correct seed for checksum (i.e. the seed from 'inode'). This +* is so that the metadata blocks will have the correct checksum after +* the migration. +* +* Note however that, if a crash occurs during the migration process, +* the recovery process is broken because the tmp_inode checksums will +* be wrong and the orphans cleanup will fail. +*/ + ei =EXT4_I (inode); +EXT4_I (tmp_inode)->i_csum_seed = ei->i_csum_seed;i_size_write (tmp_inode,i_size_read (inode));/* * Set the i_nlink to zero so it will be deleted later
@@ -524,7 +535,6 @@ int ext4_ext_migrate(struct inode *inode goto out; } - ei =EXT4_I (inode); i_data = ei->i_data;memset (&lb,0 ,sizeof (lb));
Greg Kroah-Hartman
maintainerPATCH 99/114 ext4: Fix BUG_ON in ext4_bread when write quota data
In reply to Greg Kroah-HartmanFrom: Ye Bin <[email protected]>
commit 380a0091cab482489e9b19e07f2a166ad2b76d5c upstream.
We got issue as follows when run syzkaller:
[ 167.936972] EXT4-fs error (device loop0): __ext4_remount:6314: comm rep: Abort forced by user [ 167.938306] EXT4-fs (loop0): Remounting filesystem read-only [ 167.981637] Assertion failure in ext4_getblk() at fs/ext4/inode.c:847: '(EXT4_SB(inode->i_sb)->s_mount_state & EXT4_FC_REPLAY) || handle != NULL || create == 0' [ 167.983601] ------------[ cut here ]------------ [ 167.984245] kernel BUG at fs/ext4/inode.c:847! [ 167.984882] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI [ 167.985624] CPU: 7 PID: 2290 Comm: rep Tainted: G B 5.16.0-rc5-next-20211217+ #123 [ 167.986823] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 167.988590] RIP: 0010:ext4_getblk+0x17e/0x504 [ 167.989189] Code: c6 01 74 28 49 c7 c0 a0 a3 5c 9b b9 4f 03 00 00 48 c7 c2 80 9c 5c 9b 48 c7 c6 40 b6 5c 9b 48 c7 c7 20 a4 5c 9b e8 77 e3 fd ff <0f> 0b 8b 04 244 [ 167.991679] RSP: 0018:ffff8881736f7398 EFLAGS: 00010282 [ 167.992385] RAX: 0000000000000094 RBX: 1ffff1102e6dee75 RCX: 0000000000000000 [ 167.993337] RDX: 0000000000000001 RSI: ffffffff9b6e29e0 RDI: ffffed102e6dee66 [ 167.994292] RBP: ffff88816a076210 R08: 0000000000000094 R09: ffffed107363fa09 [ 167.995252] R10: ffff88839b1fd047 R11: ffffed107363fa08 R12: ffff88816a0761e8 [ 167.996205] R13: 0000000000000000 R14: 0000000000000021 R15: 0000000000000001 [ 167.997158] FS: 00007f6a1428c740(0000) GS:ffff88839b000000(0000) knlGS:0000000000000000 [ 167.998238] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 167.999025] CR2: 00007f6a140716c8 CR3: 0000000133216000 CR4: 00000000000006e0 [ 167.999987] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 168.000944] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 168.001899] Call Trace: [ 168.002235] <TASK> [ 168.007167] ext4_bread+0xd/0x53 [ 168.007612] ext4_quota_write+0x20c/0x5c0 [ 168.010457] write_blk+0x100/0x220 [ 168.010944] remove_free_dqentry+0x1c6/0x440 [ 168.011525] free_dqentry.isra.0+0x565/0x830 [ 168.012133] remove_tree+0x318/0x6d0 [ 168.014744] remove_tree+0x1eb/0x6d0 [ 168.017346] remove_tree+0x1eb/0x6d0 [ 168.019969] remove_tree+0x1eb/0x6d0 [ 168.022128] qtree_release_dquot+0x291/0x340 [ 168.023297] v2_release_dquot+0xce/0x120 [ 168.023847] dquot_release+0x197/0x3e0 [ 168.024358] ext4_release_dquot+0x22a/0x2d0 [ 168.024932] dqput.part.0+0x1c9/0x900 [ 168.025430] __dquot_drop+0x120/0x190 [ 168.025942] ext4_clear_inode+0x86/0x220 [ 168.026472] ext4_evict_inode+0x9e8/0xa22 [ 168.028200] evict+0x29e/0x4f0 [ 168.028625] dispose_list+0x102/0x1f0 [ 168.029148] evict_inodes+0x2c1/0x3e0 [ 168.030188] generic_shutdown_super+0xa4/0x3b0 [ 168.030817] kill_block_super+0x95/0xd0 [ 168.031360] deactivate_locked_super+0x85/0xd0 [ 168.031977] cleanup_mnt+0x2bc/0x480 [ 168.033062] task_work_run+0xd1/0x170 [ 168.033565] do_exit+0xa4f/0x2b50 [ 168.037155] do_group_exit+0xef/0x2d0 [ 168.037666] __x64_sys_exit_group+0x3a/0x50 [ 168.038237] do_syscall_64+0x3b/0x90 [ 168.038751] entry_SYSCALL_64_after_hwframe+0x44/0xae
In order to reproduce this problem, the following conditions need to be met:
1. Ext4 filesystem with no journal;
2. Filesystem image with incorrect quota data;
3. Abort filesystem forced by user;
4. umount filesystem;
As in ext4_quota_write:
...
if (EXT4_SB(sb)->s_journal && !handle) {
ext4_msg(sb, KERN_WARNING, "Quota write (off=%llu, len=%llu)"
" cancelled because transaction is not started",
(unsigned long long)off, (unsigned long long)len);
return -EIO;
}...
We only check handle if NULL when filesystem has journal. There is need check handle if NULL even when filesystem has no journal.
--- fs/ext4/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ext4/super.c +1 -1
@@ -5367,7 +5367,7 @@ static ssize_t ext4_quota_write(struct sstruct buffer_head *bh;handle_t *handle =journal_current_handle (); -if (EXT4_SB (sb)->s_journal && !handle) { +if (!handle) {ext4_msg (sb,KERN_WARNING ,"Quota write (off=%llu, len=%llu)" " cancelled because transaction is not started" , (unsigned long long )off, (unsigned long long )len);
Greg Kroah-Hartman
maintainerPATCH 100/114 ext4: dont use the orphan list when migrating an inode
In reply to Greg Kroah-HartmanFrom: Theodore Ts'o <[email protected]>
commit 6eeaf88fd586f05aaf1d48cb3a139d2a5c6eb055 upstream.
We probably want to remove the indirect block to extents migration feature after a deprecation window, but until then, let's fix a potential data loss problem caused by the fact that we put the tmp_inode on the orphan list. In the unlikely case where we crash and do a journal recovery, the data blocks belonging to the inode being migrated are also represented in the tmp_inode on the orphan list --- and so its data blocks will get marked unallocated, and available for reuse.
Instead, stop putting the tmp_inode on the oprhan list. So in the case where we crash while migrating the inode, we'll leak an inode, which is not a disaster. It will be easily fixed the next time we run fsck, and it's better than potentially having blocks getting claimed by two different files, and losing data as a result.
--- fs/ext4/migrate.c | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-)
fs/ext4/migrate.c +4 -15
@@ -459,12 +459,12 @@ int ext4_ext_migrate(struct inode *inodereturn retval;/* -* Worst case we can touch the allocation bitmaps, a bgd -* block, and a block to link in the orphan list. We do need -* need to worry about credits for modifying the quota inode. +* Worst case we can touch the allocation bitmaps and a block +* group descriptor block. We do need need to worry about +* credits for modifying the quota inode. */ handle =ext4_journal_start (inode,EXT4_HT_MIGRATE , -4 +EXT4_MAXQUOTAS_TRANS_BLOCKS (inode->i_sb)); +3 +EXT4_MAXQUOTAS_TRANS_BLOCKS (inode->i_sb));if (IS_ERR (handle)) { retval =PTR_ERR (handle);
@@ -485,10 +485,6 @@ int ext4_ext_migrate(struct inode *inode* Use the correct seed for checksum (i.e. the seed from 'inode'). This * is so that the metadata blocks will have the correct checksum after * the migration. -* -* Note however that, if a crash occurs during the migration process, -* the recovery process is broken because the tmp_inode checksums will -* be wrong and the orphans cleanup will fail. */ ei =EXT4_I (inode);EXT4_I (tmp_inode)->i_csum_seed = ei->i_csum_seed;
@@ -500,7 +496,6 @@ int ext4_ext_migrate(struct inode *inodeclear_nlink (tmp_inode);ext4_ext_tree_init (handle, tmp_inode); -ext4_orphan_add (handle, tmp_inode);ext4_journal_stop (handle);/*
@@ -525,12 +520,6 @@ int ext4_ext_migrate(struct inode *inode handle =ext4_journal_start (inode,EXT4_HT_MIGRATE ,1 );if (IS_ERR (handle)) { -/* -* It is impossible to update on-disk structures without -* a handle, so just rollback in-core changes and live other -* work to orphan_list_cleanup() -*/ -ext4_orphan_del (NULL , tmp_inode); retval =PTR_ERR (handle); goto out; }
Greg Kroah-Hartman
maintainerPATCH 101/114 powerpc/fsl/dts: Enable WA for erratum A-009885 on fman3l MDIO buses
In reply to Greg Kroah-HartmanFrom: Tobias Waldekranz <[email protected]>
commit 0d375d610fa96524e2ee2b46830a46a7bfa92a9f upstream.
This block is used in (at least) T1024 and T1040, including their variants like T1023 etc.
--- arch/powerpc/boot/dts/fsl/qoriq-fman3l-0.dtsi | 2 ++ 1 file changed, 2 insertions(+)
arch/powerpc/boot/dts/fsl/qoriq-fman3l-0.dtsi +2 -0
@@ -78,6 +78,7 @@ fman0: fman@400000 { #size-cells = <0>; compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio"; reg = <0xfc000 0x1000>; + fsl,erratum-a009885; }; xmdio0: mdio@fd000 {
@@ -85,6 +86,7 @@ fman0: fman@400000 { #size-cells = <0>; compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio"; reg = <0xfd000 0x1000>; + fsl,erratum-a009885; }; ptp_timer0: ptp-timer@fe000 {
Greg Kroah-Hartman
maintainerPATCH 102/114 net/fsl: xgmac_mdio: Fix incorrect iounmap when removing module
In reply to Greg Kroah-HartmanFrom: Tobias Waldekranz <[email protected]>
commit 3f7c239c7844d2044ed399399d97a5f1c6008e1b upstream.
As reported by sparse: In the remove path, the driver would attempt to unmap its own priv pointer - instead of the io memory that it mapped in probe.
--- drivers/net/ethernet/freescale/xgmac_mdio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/freescale/xgmac_mdio.c +2 -1
@@ -304,9 +304,10 @@ err_ioremap:static int xgmac_mdio_remove (struct platform_device *pdev) {struct mii_bus *bus =platform_get_drvdata (pdev); +struct mdio_fsl_priv *priv = bus->priv;mdiobus_unregister (bus); -iounmap (bus->priv); +iounmap (priv->mdio_base);mdiobus_free (bus);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 103/114 parisc: pdc_stable: Fix memory leak in pdcs_register_pathentries
In reply to Greg Kroah-HartmanFrom: Miaoqian Lin <[email protected]>
commit d24846a4246b6e61ecbd036880a4adf61681d241 upstream.
kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add():
If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object.
Fix memory leak by calling kobject_put().
--- drivers/parisc/pdc_stable.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/parisc/pdc_stable.c +3 -1
@@ -992,8 +992,10 @@ pdcs_register_pathentries(void) entry->kobj.kset = paths_kset; err =kobject_init_and_add (&entry->kobj, &ktype_pdcspath,NULL ,"%s" , entry->name); -if (err) +if (err) { +kobject_put (&entry->kobj);return err; + }/* kobject is now registered */ write_lock (&entry->rw_lock);
Greg Kroah-Hartman
maintainerPATCH 104/114 af_unix: annote lockless accesses to unix_tot_inflight & gc_in_progress
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit 9d6d7f1cb67cdee15f1a0e85aacfb924e0e02435 upstream.
wait_for_unix_gc() reads unix_tot_inflight & gc_in_progress without synchronization.
Adds READ_ONCE()/WRITE_ONCE() and their associated comments to better document the intent.
BUG: KCSAN: data-race in unix_inflight / wait_for_unix_gc
write to 0xffffffff86e2b7c0 of 4 bytes by task 9380 on cpu 0:
unix_inflight+0x1e8/0x260 net/unix/scm.c:63 unix_attach_fds+0x10c/0x1e0 net/unix/scm.c:121 unix_scm_to_skb net/unix/af_unix.c:1674 [inline] unix_dgram_sendmsg+0x679/0x16b0 net/unix/af_unix.c:1817 unix_seqpacket_sendmsg+0xcc/0x110 net/unix/af_unix.c:2258 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg net/socket.c:724 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2409 ___sys_sendmsg net/socket.c:2463 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2549 __do_sys_sendmmsg net/socket.c:2578 [inline] __se_sys_sendmmsg net/socket.c:2575 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2575 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffffffff86e2b7c0 of 4 bytes by task 9375 on cpu 1:
wait_for_unix_gc+0x24/0x160 net/unix/garbage.c:196 unix_dgram_sendmsg+0x8e/0x16b0 net/unix/af_unix.c:1772 unix_seqpacket_sendmsg+0xcc/0x110 net/unix/af_unix.c:2258 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg net/socket.c:724 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2409 ___sys_sendmsg net/socket.c:2463 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2549 __do_sys_sendmmsg net/socket.c:2578 [inline] __se_sys_sendmmsg net/socket.c:2575 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2575 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0x00000002 -> 0x00000004
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 9375 Comm: syz-executor.1 Not tainted 5.16.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
--- net/unix/garbage.c | 14 +++++++++++--- net/unix/scm.c | 6 ++++-- 2 files changed, 15 insertions(+), 5 deletions(-)
net/unix/garbage.c +11 -3
@@ -197,8 +197,11 @@ void wait_for_unix_gc(void) {/* If number of inflight sockets is insane, * force a garbage collect right now. +* Paired with the WRITE_ONCE() in unix_inflight(), +* unix_notinflight() and gc_in_progress(). */ -if (unix_tot_inflight >UNIX_INFLIGHT_TRIGGER_GC && !gc_in_progress) +if (READ_ONCE (unix_tot_inflight) >UNIX_INFLIGHT_TRIGGER_GC && + !READ_ONCE (gc_in_progress))unix_gc ();wait_event (unix_gc_wait, gc_in_progress == false); }
@@ -218,7 +221,9 @@ void unix_gc(void)if (gc_in_progress) goto out; - gc_in_progress = true; +/* Paired with READ_ONCE() in wait_for_unix_gc(). */ +WRITE_ONCE (gc_in_progress, true); +/* First, select candidates for garbage collection. Only * in-flight sockets are considered, and from those only ones * which don't have any external reference.
@@ -304,7 +309,10 @@ void unix_gc(void)/* All candidates should have been detached by now. */ BUG_ON (!list_empty (&gc_candidates)); - gc_in_progress = false; + +/* Paired with READ_ONCE() in wait_for_unix_gc(). */ +WRITE_ONCE (gc_in_progress, false); +wake_up (&unix_gc_wait); out:
net/unix/scm.c +4 -2
@@ -56,7 +56,8 @@ void unix_inflight(struct user_struct *u }else {BUG_ON (list_empty (&u->link)); } - unix_tot_inflight++; +/* Paired with READ_ONCE() in wait_for_unix_gc() */ +WRITE_ONCE (unix_tot_inflight, unix_tot_inflight +1 ); } user->unix_inflight++;spin_unlock (&unix_gc_lock);
@@ -76,7 +77,8 @@ void unix_notinflight(struct user_structif (atomic_long_dec_and_test (&u->inflight))list_del_init (&u->link); - unix_tot_inflight--; +/* Paired with READ_ONCE() in wait_for_unix_gc() */ +WRITE_ONCE (unix_tot_inflight, unix_tot_inflight -1 ); } user->unix_inflight--;spin_unlock (&unix_gc_lock);
Greg Kroah-Hartman
maintainerPATCH 105/114 net: axienet: Wait for PhyRstCmplt after core reset
In reply to Greg Kroah-HartmanFrom: Robert Hancock <[email protected]>
commit b400c2f4f4c53c86594dd57098970d97d488bfde upstream.
When resetting the device, wait for the PhyRstCmplt bit to be set in the interrupt status register before continuing initialization, to ensure that the core is actually ready. When using an external PHY, this also ensures we do not start trying to access the PHY while it is still in reset. The PHY reset is initiated by the core reset which is triggered just above, but remains asserted for 5ms after the core is reset according to the documentation.
The MgtRdy bit could also be waited for, but unfortunately when using 7-series devices, the bit does not appear to work as documented (it seems to behave as some sort of link state indication and not just an indication the transceiver is ready) so it can't really be relied on for this purpose.
--- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/net/ethernet/xilinx/xilinx_axienet_main.c +10 -0
@@ -278,6 +278,16 @@ static int axienet_dma_bd_init(struct neaxienet_dma_out32 (lp,XAXIDMA_TX_CR_OFFSET , cr |XAXIDMA_CR_RUNSTOP_MASK ); +/* Wait for PhyRstCmplt bit to be set, indicating the PHY reset has finished */ + ret =read_poll_timeout (axienet_ior, value, + value &XAE_INT_PHYRSTCMPLT_MASK , +DELAY_OF_ONE_MILLISEC ,50000 , false, lp, +XAE_IS_OFFSET ); +if (ret) { +dev_err (lp->dev,"%s: timeout waiting for PhyRstCmplt\n" , __func__); +return ret; + } +return 0 ; out:axienet_dma_bd_release (ndev);
Greg Kroah-Hartman
maintainerPATCH 106/114 net: axienet: fix number of TX ring slots for available check
In reply to Greg Kroah-HartmanFrom: Robert Hancock <[email protected]>
commit aba57a823d2985a2cc8c74a2535f3a88e68d9424 upstream.
The check for the number of available TX ring slots was off by 1 since a slot is required for the skb header as well as each fragment. This could result in overwriting a TX ring slot that was still in use.
--- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/xilinx/xilinx_axienet_main.c +2 -2
@@ -681,7 +681,7 @@ axienet_start_xmit(struct sk_buff *skb, num_frag =skb_shinfo (skb)->nr_frags; cur_p = &lp->tx_bd_v[lp->tx_bd_tail]; -if (axienet_check_tx_bd_space (lp, num_frag)) { +if (axienet_check_tx_bd_space (lp, num_frag +1 )) {if (netif_queue_stopped (ndev))return NETDEV_TX_BUSY ;
@@ -691,7 +691,7 @@ axienet_start_xmit(struct sk_buff *skb,smp_mb ();/* Space might have just been freed - check again */ -if (axienet_check_tx_bd_space (lp, num_frag)) +if (axienet_check_tx_bd_space (lp, num_frag +1 ))return NETDEV_TX_BUSY ;netif_wake_queue (ndev);
Greg Kroah-Hartman
maintainerPATCH 107/114 netns: add schedule point in ops_exit_list()
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit 2836615aa22de55b8fca5e32fe1b27a67cda625e upstream.
When under stress, cleanup_net() can have to dismantle netns in big numbers. ops_exit_list() currently calls many helpers [1] that have no schedule point, and we can end up with soft lockups, particularly on hosts with many cpus.
Even for moderate amount of netns processed by cleanup_net() this patch avoids latency spikes.
[1] Some of these helpers like fib_sync_up() and fib_sync_down_dev() are very slow because net/ipv4/fib_semantics.c uses host-wide hash tables, and ifindex is used as the only input of two hash functions. ifindexes tend to be the same for all netns (lo.ifindex==1 per instance) This will be fixed in a separate patch.
--- net/core/net_namespace.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/core/net_namespace.c +3 -1
@@ -130,8 +130,10 @@ static void ops_exit_list(const struct p {struct net *net;if (ops->exit) { -list_for_each_entry (net, net_exit_list, exit_list) +list_for_each_entry (net, net_exit_list, exit_list) { ops->exit (net); +cond_resched (); + } }if (ops->exit_batch) ops->exit_batch (net_exit_list);
Greg Kroah-Hartman
maintainerPATCH 108/114 dmaengine: at_xdmac: Dont start transactions at tx_submit level
In reply to Greg Kroah-HartmanFrom: Tudor Ambarus <[email protected]>
commit bccfb96b59179d4f96cbbd1ddff8fac6d335eae4 upstream.
tx_submit is supposed to push the current transaction descriptor to a pending queue, waiting for issue_pending() to be called. issue_pending() must start the transfer, not tx_submit(), thus remove at_xdmac_start_xfer() from at_xdmac_tx_submit(). Clients of at_xdmac that assume that tx_submit() starts the transfer must be updated and call dma_async_issue_pending() if they miss to call it (one example is atmel_serial).
As the at_xdmac_start_xfer() is now called only from at_xdmac_advance_work() when !at_xdmac_chan_is_enabled(), the at_xdmac_chan_is_enabled() check is no longer needed in at_xdmac_start_xfer(), thus remove it.
--- drivers/dma/at_xdmac.c | 6 ------ 1 file changed, 6 deletions(-)
drivers/dma/at_xdmac.c +0 -6
@@ -345,9 +345,6 @@ static void at_xdmac_start_xfer(struct adev_vdbg (chan2dev (&atchan->chan),"%s: desc 0x%p\n" , __func__, first); -if (at_xdmac_chan_is_enabled (atchan)) -return ; -/* Set transfer as active to not try to start it again. */ first->active_xfer = true;
@@ -431,9 +428,6 @@ static dma_cookie_t at_xdmac_tx_submit(sdev_vdbg (chan2dev (tx->chan),"%s: atchan 0x%p, add desc 0x%p to xfers_list\n" , __func__, atchan, desc);list_add_tail (&desc->xfer_node, &atchan->xfers_list); -if (list_is_singular (&atchan->xfers_list)) -at_xdmac_start_xfer (atchan, desc); -spin_unlock_irqrestore (&atchan->lock, irqflags);return cookie; }
Greg Kroah-Hartman
maintainerPATCH 109/114 dmaengine: at_xdmac: Print debug message after realeasing the lock
In reply to Greg Kroah-HartmanFrom: Tudor Ambarus <[email protected]>
commit 5edc24ac876a928f36f407a0fcdb33b94a3a210f upstream.
It is desirable to do the prints without the lock held if possible, so move the print after the lock is released.
--- drivers/dma/at_xdmac.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/dma/at_xdmac.c +4 -2
@@ -425,10 +425,12 @@ static dma_cookie_t at_xdmac_tx_submit(sspin_lock_irqsave (&atchan->lock, irqflags); cookie =dma_cookie_assign (tx); -dev_vdbg (chan2dev (tx->chan),"%s: atchan 0x%p, add desc 0x%p to xfers_list\n" , - __func__, atchan, desc);list_add_tail (&desc->xfer_node, &atchan->xfers_list);spin_unlock_irqrestore (&atchan->lock, irqflags); + +dev_vdbg (chan2dev (tx->chan),"%s: atchan 0x%p, add desc 0x%p to xfers_list\n" , + __func__, atchan, desc); +return cookie; }
Greg Kroah-Hartman
maintainerPATCH 110/114 dmaengine: at_xdmac: Fix lld view setting
In reply to Greg Kroah-HartmanFrom: Tudor Ambarus <[email protected]>
commit 1385eb4d14d447cc5d744bc2ac34f43be66c9963 upstream.
AT_XDMAC_CNDC_NDVIEW_NDV3 was set even for AT_XDMAC_MBR_UBC_NDV2, because of the wrong bit handling. Fix it.
--- drivers/dma/at_xdmac.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/dma/at_xdmac.c +3 -1
@@ -100,6 +100,7 @@#define AT_XDMAC_CNDC_NDE (0x1 << 0)/* Channel x Next Descriptor Enable */ #define AT_XDMAC_CNDC_NDSUP (0x1 << 1)/* Channel x Next Descriptor Source Update */ #define AT_XDMAC_CNDC_NDDUP (0x1 << 2)/* Channel x Next Descriptor Destination Update */ +#define AT_XDMAC_CNDC_NDVIEW_MASK GENMASK(28, 27)#define AT_XDMAC_CNDC_NDVIEW_NDV0 (0x0 << 3)/* Channel x Next Descriptor View 0 */ #define AT_XDMAC_CNDC_NDVIEW_NDV1 (0x1 << 3)/* Channel x Next Descriptor View 1 */ #define AT_XDMAC_CNDC_NDVIEW_NDV2 (0x2 << 3)/* Channel x Next Descriptor View 2 */
@@ -360,7 +361,8 @@ static void at_xdmac_start_xfer(struct a*/ if (at_xdmac_chan_is_cyclic (atchan)) reg =AT_XDMAC_CNDC_NDVIEW_NDV1 ; -else if (first->lld.mbr_ubc &AT_XDMAC_MBR_UBC_NDV3 ) +else if ((first->lld.mbr_ubc & +AT_XDMAC_CNDC_NDVIEW_MASK ) ==AT_XDMAC_MBR_UBC_NDV3 ) reg =AT_XDMAC_CNDC_NDVIEW_NDV3 ;else reg =AT_XDMAC_CNDC_NDVIEW_NDV2 ;
Greg Kroah-Hartman
maintainerPATCH 111/114 dmaengine: at_xdmac: Fix at_xdmac_lld struct definition
In reply to Greg Kroah-HartmanFrom: Tudor Ambarus <[email protected]>
commit 912f7c6f7fac273f40e621447cf17d14b50d6e5b upstream.
The hardware channel next descriptor view structure contains just fields of 32 bits, while dma_addr_t can be of type u64 or u32 depending on CONFIG_ARCH_DMA_ADDR_T_64BIT. Force u32 to comply with what the hardware expects.
--- drivers/dma/at_xdmac.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/dma/at_xdmac.c +9 -9
@@ -233,15 +233,15 @@ struct at_xdmac {/* Linked List Descriptor */ struct at_xdmac_lld { -dma_addr_t mbr_nda;/* Next Descriptor Member */ -u32 mbr_ubc;/* Microblock Control Member */ -dma_addr_t mbr_sa;/* Source Address Member */ -dma_addr_t mbr_da;/* Destination Address Member */ -u32 mbr_cfg;/* Configuration Register */ -u32 mbr_bc;/* Block Control Register */ -u32 mbr_ds;/* Data Stride Register */ -u32 mbr_sus;/* Source Microblock Stride Register */ -u32 mbr_dus;/* Destination Microblock Stride Register */ +u32 mbr_nda;/* Next Descriptor Member */ +u32 mbr_ubc;/* Microblock Control Member */ +u32 mbr_sa;/* Source Address Member */ +u32 mbr_da;/* Destination Address Member */ +u32 mbr_cfg;/* Configuration Register */ +u32 mbr_bc;/* Block Control Register */ +u32 mbr_ds;/* Data Stride Register */ +u32 mbr_sus;/* Source Microblock Stride Register */ +u32 mbr_dus;/* Destination Microblock Stride Register */ };/* 64-bit alignment needed to update CNDA and CUBC registers in an atomic way. */
Greg Kroah-Hartman
maintainerPATCH 112/114 net_sched: restore "mpu xxx" handling
In reply to Greg Kroah-HartmanFrom: Kevin Bracey <[email protected]>
commit fb80445c438c78b40b547d12b8d56596ce4ccfeb upstream.
commit 56b765b79e9a ("htb: improved accuracy at high rates") broke "overhead X", "linklayer atm" and "mpu X" attributes.
"overhead X" and "linklayer atm" have already been fixed. This restores the "mpu X" handling, as might be used by DOCSIS or Ethernet shaping:
tc class add ... htb rate X overhead 4 mpu 64
The code being fixed is used by htb, tbf and act_police. Cake has its own mpu handling. qdisc_calculate_pkt_len still uses the size table containing values adjusted for mpu by user space.
iproute2 tc has always passed mpu into the kernel via a tc_ratespec structure, but the kernel never directly acted on it, merely stored it so that it could be read back by tc class show.
Rather, tc would generate length-to-time tables that included the mpu (and linklayer) in their construction, and the kernel used those tables.
Since v3.7, the tables were no longer used. Along with "mpu", this also broke "overhead" and "linklayer" which were fixed in 01cb71d2d47b ("net_sched: restore "overhead xxx" handling", v3.10) and 8a8e3d84b171 ("net_sched: restore "linklayer atm" handling", v3.11).
"overhead" was fixed by simply restoring use of tc_ratespec::overhead - this had originally been used by the kernel but was initially omitted from the new non-table-based calculations.
"linklayer" had been handled in the table like "mpu", but the mode was not originally passed in tc_ratespec. The new implementation was made to handle it by getting new versions of tc to pass the mode in an extended tc_ratespec, and for older versions of tc the table contents were analysed at load time to deduce linklayer.
As "mpu" has always been given to the kernel in tc_ratespec, accompanying the mpu-based table, we can restore system functionality with no userspace change by making the kernel act on the tc_ratespec value.
--- include/net/sch_generic.h | 5 +++++ net/sched/sch_generic.c | 1 + 2 files changed, 6 insertions(+)
include/net/sch_generic.h +5 -0
@@ -797,6 +797,7 @@ struct psched_ratecfg {u64 rate_bytes_ps;/* bytes per second */ u32 mult;u16 overhead; +u16 mpu;u8 linklayer;u8 shift; };
@@ -806,6 +807,9 @@ static inline u64 psched_l2t_ns(const st { len += r->overhead; +if (len < r->mpu) + len = r->mpu; +if (unlikely (r->linklayer ==TC_LINKLAYER_ATM ))return ((u64)(DIV_ROUND_UP (len,48 )*53 ) * r->mult) >> r->shift;
@@ -828,6 +832,7 @@ static inline void psched_ratecfg_getrat res->rate =min_t (u64, r->rate_bytes_ps, ~0U ); res->overhead = r->overhead; + res->mpu = r->mpu; res->linklayer = (r->linklayer &TC_LINKLAYER_MASK ); }
net/sched/sch_generic.c +1 -0
@@ -966,6 +966,7 @@ void psched_ratecfg_precompute(struct ps {memset (r,0 ,sizeof (*r)); r->overhead = conf->overhead; + r->mpu = conf->mpu; r->rate_bytes_ps =max_t (u64, conf->rate, rate64); r->linklayer = (conf->linklayer &TC_LINKLAYER_MASK ); r->mult =1 ;
Greg Kroah-Hartman
maintainerPATCH 113/114 bcmgenet: add WOL IRQ check
In reply to Greg Kroah-HartmanFrom: Sergey Shtylyov <[email protected]>
commit 9deb48b53e7f4056c2eaa2dc2ee3338df619e4f6 upstream.
The driver neglects to check the result of platform_get_irq_optional()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL. Stop calling devm_request_irq() with the invalid IRQ #s.
--- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/net/ethernet/broadcom/genet/bcmgenet.c +6 -4
@@ -3443,10 +3443,12 @@ static int bcmgenet_probe(struct platfor/* Request the WOL interrupt and advertise suspend if available */ priv->wol_irq_disabled = true; - err =devm_request_irq (&pdev->dev, priv->wol_irq, bcmgenet_wol_isr,0 , - dev->name, priv); -if (!err) -device_set_wakeup_capable (&pdev->dev,1 ); +if (priv->wol_irq >0 ) { + err =devm_request_irq (&pdev->dev, priv->wol_irq, + bcmgenet_wol_isr,0 , dev->name, priv); +if (!err) +device_set_wakeup_capable (&pdev->dev,1 ); + }/* Set the needed headroom to account for any possible * features enabling/disabling at runtime
Greg Kroah-Hartman
maintainerPATCH 114/114 lib82596: Fix IRQ check in sni_82596_probe
In reply to Greg Kroah-HartmanFrom: Miaoqian Lin <[email protected]>
commit 99218cbf81bf21355a3de61cd46a706d36e900e6 upstream.
platform_get_irq() returns negative error number instead 0 on failure. And the doc of platform_get_irq() provides a usage example:
int irq = platform_get_irq(pdev, 0);
if (irq < 0)
return irq;Fix the check of return value to catch errors correctly.
--- drivers/net/ethernet/i825xx/sni_82596.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/i825xx/sni_82596.c +2 -1
@@ -122,9 +122,10 @@ static int sni_82596_probe(struct platfo netdevice->dev_addr[5 ] =readb (eth_addr +0x06 );iounmap (eth_addr); -if (!netdevice->irq) { +if (netdevice->irq <0 ) {printk (KERN_ERR "%s: IRQ not found for i82596 at 0x%lx\n" , __FILE__, netdevice->base_addr); + retval = netdevice->irq; goto probe_failed; }
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 4.4.300 release. There are 114 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.4.y
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.300 release. There are 114 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Jan 2022 18:39:11 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.300-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.300 release. There are 114 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Jan 2022 18:39:11 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.300-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 4.4.300-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-4.4.y
* git commit: 5b24bd65b9e3c88e7fa0a702a1b7932378185687
* git describe: v4.4.299-115-g5b24bd65b9e3
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.4.y/build/v4.4.299-115-g5b24bd65b9e3
## Test Regressions (compared to v4.4.299-10-g5f58931b34ba) No test regressions found.
## Metric Regressions (compared to v4.4.299-10-g5f58931b34ba) No metric regressions found.
## Test Fixes (compared to v4.4.299-10-g5f58931b34ba) No test fixes found.
## Metric Fixes (compared to v4.4.299-10-g5f58931b34ba) No metric fixes found.
## Test result summary
total: 51089, pass: 41245, fail: 231, skip: 8346, xfail: 1267
## Build Summary
* arm: 129 total, 129 passed, 0 failed
* arm64: 31 total, 31 passed, 0 failed
* i386: 18 total, 18 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 22 total, 22 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 30 total, 24 passed, 6 failed
## Test suites summary
* fwts
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.300 release. There are 114 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Jan 2022 18:39:11 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.300-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.4:
6 builds: 6 pass, 0 fail
12 boots: 12 pass, 0 fail
30 tests: 30 pass, 0 failLinux version: 4.4.300-rc1-g67ca9c44f63d
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04
Jon
Hi Greg,
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.300 release. There are 114 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Jan 2022 18:39:11 +0000. Anything received after that time might be too late.
A new version of this branch was pushed into the stable-queue git repository around 10:30 PST, AFAICS without any actual changes. This caused all my builders to start from scratch (again). Would it be possible to avoid such dummy pushes ?
Thanks,
Guenter
Greg Kroah-Hartman
maintainerQuoted 8 lines · Guenter Roeck
Hi Greg,
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.300 release. There are 114 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 8 lines
Quoted 3 lines
Responses should be made by Wed, 26 Jan 2022 18:39:11 +0000. Anything received after that time might be too late.
A new version of this branch was pushed into the stable-queue git repository around 10:30 PST, AFAICS without any actual changes. This caused all my builders to start from scratch (again). Would it be possible to avoid such dummy pushes ?
I'll try to avoid it, but it is usually easier for me to do "generate all -rcs and push them out", than do to them individually, which is why this happened.
sorry,
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.300 release. There are 114 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Jan 2022 18:39:11 +0000. Anything received after that time might be too late.
Build results:
total: 160 pass: 160 fail: 0 Qemu test results: total: 342 pass: 342 fail: 0
Guenter