When request_irq() fails, the region allocated by request_region()
is not released. Fix this by calling release_region() before returning.
Smatch warning:
drivers/gpib/cb7210/cb7210.c:1068 cb_isa_attach() warn: 'config->ibbase'
from __request_region() not released on lines: 1064.
Fixes: 82e3508046 ("staging: gpib: cb7210 console messaging cleanup")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Link: https://patch.msgid.link/20260503093036.283546-1-zenghongling@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d1857f8296 ("gpib: fix use-after-free in IO ioctl handlers")
introduced a descriptor_busy reference counter to pin struct
gpib_descriptor across IO ioctl operations. In command_ioctl(), the
error path inside the loop decrements descriptor_busy and breaks, but
execution then falls through to the unconditional decrement after the
loop, underflowing the counter to -1.
This re-enables the use-after-free that the original fix was meant to
prevent: a concurrent close_dev_ioctl() sees descriptor_busy == 0 on
an actively-used descriptor and frees it.
Remove the early decrement from the error path. The post-loop
decrement already handles all exit paths, matching the correct pattern
used in read_ioctl() and write_ioctl().
Fixes: d1857f8296 ("gpib: fix use-after-free in IO ioctl handlers")
Reported-by: Ruikai Peng <ruikai@pwno.io>
Signed-off-by: Adam Crosser <adam.crosser@praetorian.com>
Link: https://patch.msgid.link/20260424123750.855863-1-adam.r.crosser@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The agilent_82357a driver uses the USB device serial string for device
matching but does not verify that the string exists before passing it
to strcmp().
Verify that the device has a serial number before accessing it to avoid
triggering a NULL-pointer dereference with devices that don't provide
a serial number (iSerialNumber = 0).
Similar to commit aa79f996eb ("i2c: cp2615: fix serial string
NULL-deref at probe").
Found by Claude:sonnet-4.5
Signed-off-by: Joe Simmons-Talbott <joest@redhat.com>
Acked-by: Dave Penkler <dpenkler@gmail.com>
Link: https://patch.msgid.link/20260326131256.1758014-1-joest@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The NI USB adapter sets the END bit in the status word when an error
occurs such as a read being interrupted by the setting of ATN. This
happens for example when a device clear is received from the
controller in charge during a read.
The common driver changes the error return to 0 whenever the END bit
is set in order to avoid errors such as timeout or interrupt to be
reported after the full message has actually been read. The behaviour
of the NI USB adapter in setting the END bit on errors was causing
actual errors (-EINTR, -ETIMEDOUT) not to be reported.
We avoid setting the END bit in the ni_usb_gpib driver when an error
is reported in error_code of the status from the adaptor.
Signed-off-by: Dave Penkler <dpenkler@gmail.com>
Link: https://patch.msgid.link/20260422074807.3194-1-dpenkler@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The IBRD, IBWRT, IBCMD, and IBWAIT ioctl handlers use a gpib_descriptor
pointer after board->big_gpib_mutex has been released. A concurrent
IBCLOSEDEV ioctl can free the descriptor via close_dev_ioctl() during
this window, causing a use-after-free.
The IO handlers (read_ioctl, write_ioctl, command_ioctl) explicitly
release big_gpib_mutex before calling their handler. wait_ioctl() is
called with big_gpib_mutex held, but ibwait() releases it internally
when wait_mask is non-zero. In all four cases, the descriptor pointer
obtained from handle_to_descriptor() becomes unprotected.
Fix this by introducing a kernel-only descriptor_busy reference count
in struct gpib_descriptor. Each handler atomically increments
descriptor_busy under file_priv->descriptors_mutex before releasing the
lock, and decrements it when done. close_dev_ioctl() checks
descriptor_busy under the same lock and rejects the close with -EBUSY
if the count is non-zero.
A reference count rather than a simple flag is necessary because
multiple handlers can operate on the same descriptor concurrently
(e.g. IBRD and IBWAIT on the same handle from different threads).
A separate counter is needed because io_in_progress can be cleared from
unprivileged userspace via the IBWAIT ioctl (through general_ibstatus()
with set_mask containing CMPL), which would allow an attacker to bypass
a check based solely on io_in_progress. The new descriptor_busy
counter is only modified by the kernel IO paths.
The lock ordering is consistent (big_gpib_mutex -> descriptors_mutex)
and the handlers only hold descriptors_mutex briefly during the lookup,
so there is no deadlock risk and no impact on IO throughput.
Signed-off-by: Adam Crosser <adam.crosser@praetorian.com>
Cc: stable <stable@kernel.org>
Reviewed-by: Dave Penkler <dpenkler@gmail.com>
Tested-by: Dave Penkler <dpenkler@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver iterates over the registered USB interfaces during GPIB
attach and takes a reference to their USB devices until a match is
found. These references are never released which leads to a memory leak
when devices are disconnected.
Fix the leak by dropping the unnecessary references.
Fixes: fce79512a9 ("staging: gpib: Add LPVO DIY USB GPIB driver")
Cc: stable <stable@kernel.org> # 6.13
Cc: Dave Penkler <dpenkler@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260310105127.17538-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The following errors were reported for a s390 randconfig build
of the fluke gpib driver:
>> drivers/gpib/eastwood/fluke_gpib.c:1002:23: error: call to undeclared function 'ioremap'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
1002 | nec_priv->mmiobase = ioremap(e_priv->gpib_iomem_res->start,
| ^
>> drivers/gpib/eastwood/fluke_gpib.c:1002:21: error: incompatible integer to pointer conversion assigning to 'void *' from 'int' [-Wint-conversion]
1002 | nec_priv->mmiobase = ioremap(e_priv->gpib_iomem_res->start,
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1003 | resource_size(e_priv->gpib_iomem_res));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpib/eastwood/fluke_gpib.c:1036:33: error: incompatible integer to pointer conversion assigning to 'void *' from 'int' [-Wint-conversion]
1036 | e_priv->write_transfer_counter = ioremap(e_priv->write_transfer_counter_res->start,
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1037 | resource_size(e_priv->write_transfer_counter_res));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Add HAS_IOMEM dependency to Kconfig for fluke driver option
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601221748.AFAqHieJ-lkp@intel.com/
Fixes: baf8855c91 ("staging: gpib: fix address space mixup")
Cc: stable <stable@kernel.org>
Signed-off-by: Dave Penkler <dpenkler@gmail.com>
Link: https://patch.msgid.link/20260202094755.4259-1-dpenkler@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260305102745.12032-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260305102745.12032-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The LPVO driver apparently includes a more or less verbatim copy of the
USB skeleton driver.
Replace the "skel_" symbol prefix with "lpvo_" and rename the "usb_skel"
struct "lpvo" to avoid symbol name clashes and make this a bit more
palatable.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260305151729.10501-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The LPVO USB GPIB adapter apparently uses an FTDI 8U232AM with the
default PID, but this device id is already handled by the ftdi_sio
serial driver.
Stop binding to the default PID to avoid breaking existing setups with
FTDI 8U232AM.
Anyone using this driver should blacklist the ftdi_sio driver and add
the device id manually through sysfs (e.g. using udev rules).
Fixes: fce79512a9 ("staging: gpib: Add LPVO DIY USB GPIB driver")
Fixes: e6ab504633 ("staging: gpib: Destage gpib")
Cc: Dave Penkler <dpenkler@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260305151729.10501-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This converts some of the visually simpler cases that have been split
over multiple lines. I only did the ones that are easy to verify the
resulting diff by having just that final GFP_KERNEL argument on the next
line.
Somebody should probably do a proper coccinelle script for this, but for
me the trivial script actually resulted in an assertion failure in the
middle of the script. I probably had made it a bit _too_ trivial.
So after fighting that far a while I decided to just do some of the
syntactically simpler cases with variations of the previous 'sed'
scripts.
The more syntactically complex multi-line cases would mostly really want
whitespace cleanup anyway.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
