<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/staging, branch v6.18.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>staging: fbtft: core: fix potential memory leak in fbtft_probe_common()</title>
<updated>2025-12-18T13:03:16+00:00</updated>
<author>
<name>Jianglei Nie</name>
<email>niejianglei2021@163.com</email>
</author>
<published>2025-11-12T19:22:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=56296da5e6bf558cd8b91108a356cbd7cd35adbf'/>
<id>56296da5e6bf558cd8b91108a356cbd7cd35adbf</id>
<content type='text'>
[ Upstream commit 47d3949a9b04cbcb0e10abae30c2b53e98706e11 ]

fbtft_probe_common() allocates a memory chunk for "info" with
fbtft_framebuffer_alloc(). When "display-&gt;buswidth == 0" is true, the
function returns without releasing the "info", which will lead to a
memory leak.

Fix it by calling fbtft_framebuffer_release() when "display-&gt;buswidth
== 0" is true.

Fixes: c296d5f9957c ("staging: fbtft: core support")
Signed-off-by: Jianglei Nie &lt;niejianglei2021@163.com&gt;
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Acked-by: Abdun Nihaal &lt;abdun.nihaal@gmail.com&gt;
Link: https://patch.msgid.link/20251112192235.2088654-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 47d3949a9b04cbcb0e10abae30c2b53e98706e11 ]

fbtft_probe_common() allocates a memory chunk for "info" with
fbtft_framebuffer_alloc(). When "display-&gt;buswidth == 0" is true, the
function returns without releasing the "info", which will lead to a
memory leak.

Fix it by calling fbtft_framebuffer_release() when "display-&gt;buswidth
== 0" is true.

Fixes: c296d5f9957c ("staging: fbtft: core support")
Signed-off-by: Jianglei Nie &lt;niejianglei2021@163.com&gt;
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Acked-by: Abdun Nihaal &lt;abdun.nihaal@gmail.com&gt;
Link: https://patch.msgid.link/20251112192235.2088654-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: most: remove broken i2c driver</title>
<updated>2025-12-18T13:02:54+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2025-10-29T09:34:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e463548fd80e779efea1cb2d3049b8a7231e6925'/>
<id>e463548fd80e779efea1cb2d3049b8a7231e6925</id>
<content type='text'>
[ Upstream commit 495df2da6944477d282d5cc0c13174d06e25b310 ]

The MOST I2C driver has been completely broken for five years without
anyone noticing so remove the driver from staging.

Specifically, commit 723de0f9171e ("staging: most: remove device from
interface structure") started requiring drivers to set the interface
device pointer before registration, but the I2C driver was never updated
which results in a NULL pointer dereference if anyone ever tries to
probe it.

Fixes: 723de0f9171e ("staging: most: remove device from interface structure")
Cc: Christian Gromm &lt;christian.gromm@microchip.com&gt;
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Link: https://patch.msgid.link/20251029093442.29256-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 495df2da6944477d282d5cc0c13174d06e25b310 ]

The MOST I2C driver has been completely broken for five years without
anyone noticing so remove the driver from staging.

Specifically, commit 723de0f9171e ("staging: most: remove device from
interface structure") started requiring drivers to set the interface
device pointer before registration, but the I2C driver was never updated
which results in a NULL pointer dereference if anyone ever tries to
probe it.

Fixes: 723de0f9171e ("staging: most: remove device from interface structure")
Cc: Christian Gromm &lt;christian.gromm@microchip.com&gt;
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Link: https://patch.msgid.link/20251029093442.29256-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing</title>
<updated>2025-12-12T17:42:47+00:00</updated>
<author>
<name>Navaneeth K</name>
<email>knavaneeth786@gmail.com</email>
</author>
<published>2025-11-20T16:35:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bf323db1d883c209880bd92f3b12503e3531c3fc'/>
<id>bf323db1d883c209880bd92f3b12503e3531c3fc</id>
<content type='text'>
commit 502ddcc405b69fa92e0add6c1714d654504f6fd7 upstream.

The Extended Supported Rates (ESR) IE handling in OnBeacon accessed
*(p + 1 + ielen) and *(p + 2 + ielen) without verifying that these
offsets lie within the received frame buffer. A malformed beacon with
an ESR IE positioned at the end of the buffer could cause an
out-of-bounds read, potentially triggering a kernel panic.

Add a boundary check to ensure that the ESR IE body and the subsequent
bytes are within the limits of the frame before attempting to access
them.

This prevents OOB reads caused by malformed beacon frames.

Signed-off-by: Navaneeth K &lt;knavaneeth786@gmail.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 502ddcc405b69fa92e0add6c1714d654504f6fd7 upstream.

The Extended Supported Rates (ESR) IE handling in OnBeacon accessed
*(p + 1 + ielen) and *(p + 2 + ielen) without verifying that these
offsets lie within the received frame buffer. A malformed beacon with
an ESR IE positioned at the end of the buffer could cause an
out-of-bounds read, potentially triggering a kernel panic.

Add a boundary check to ensure that the ESR IE body and the subsequent
bytes are within the limits of the frame before attempting to access
them.

This prevents OOB reads caused by malformed beacon frames.

Signed-off-by: Navaneeth K &lt;knavaneeth786@gmail.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing</title>
<updated>2025-12-12T17:42:47+00:00</updated>
<author>
<name>Navaneeth K</name>
<email>knavaneeth786@gmail.com</email>
</author>
<published>2025-11-20T16:33:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e841d8ea722315b781c4fc5bf4f7670fbca88875'/>
<id>e841d8ea722315b781c4fc5bf4f7670fbca88875</id>
<content type='text'>
commit 6ef0e1c10455927867cac8f0ed6b49f328f8cf95 upstream.

The Supported Rates IE length from an incoming Association Request frame
was used directly as the memcpy() length when copying into a fixed-size
16-byte stack buffer (supportRate). A malicious station can advertise an
IE length larger than 16 bytes, causing a stack buffer overflow.

Clamp ie_len to the buffer size before copying the Supported Rates IE,
and correct the bounds check when merging Extended Supported Rates to
prevent a second potential overflow.

This prevents kernel stack corruption triggered by malformed association
requests.

Signed-off-by: Navaneeth K &lt;knavaneeth786@gmail.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6ef0e1c10455927867cac8f0ed6b49f328f8cf95 upstream.

The Supported Rates IE length from an incoming Association Request frame
was used directly as the memcpy() length when copying into a fixed-size
16-byte stack buffer (supportRate). A malicious station can advertise an
IE length larger than 16 bytes, causing a stack buffer overflow.

Clamp ie_len to the buffer size before copying the Supported Rates IE,
and correct the bounds check when merging Extended Supported Rates to
prevent a second potential overflow.

This prevents kernel stack corruption triggered by malformed association
requests.

Signed-off-by: Navaneeth K &lt;knavaneeth786@gmail.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser</title>
<updated>2025-12-12T17:42:47+00:00</updated>
<author>
<name>Navaneeth K</name>
<email>knavaneeth786@gmail.com</email>
</author>
<published>2025-11-20T16:23:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c0d93d69e1472ba75b78898979b90a98ba2a2501'/>
<id>c0d93d69e1472ba75b78898979b90a98ba2a2501</id>
<content type='text'>
commit 154828bf9559b9c8421fc2f0d7f7f76b3683aaed upstream.

The Information Element (IE) parser rtw_get_ie() trusted the length
byte of each IE without validating that the IE body (len bytes after
the 2-byte header) fits inside the remaining frame buffer. A malformed
frame can advertise an IE length larger than the available data, causing
the parser to increment its pointer beyond the buffer end. This results
in out-of-bounds reads or, depending on the pattern, an infinite loop.

Fix by validating that (offset + 2 + len) does not exceed the limit
before accepting the IE or advancing to the next element.

This prevents OOB reads and ensures the parser terminates safely on
malformed frames.

Signed-off-by: Navaneeth K &lt;knavaneeth786@gmail.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 154828bf9559b9c8421fc2f0d7f7f76b3683aaed upstream.

The Information Element (IE) parser rtw_get_ie() trusted the length
byte of each IE without validating that the IE body (len bytes after
the 2-byte header) fits inside the remaining frame buffer. A malformed
frame can advertise an IE length larger than the available data, causing
the parser to increment its pointer beyond the buffer end. This results
in out-of-bounds reads or, depending on the pattern, an infinite loop.

Fix by validating that (offset + 2 + len) does not exceed the limit
before accepting the IE or advancing to the next element.

This prevents OOB reads and ensures the parser terminates safely on
malformed frames.

Signed-off-by: Navaneeth K &lt;knavaneeth786@gmail.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: gpib: Fix device reference leak in fmh_gpib driver</title>
<updated>2025-10-13T08:55:03+00:00</updated>
<author>
<name>Ma Ke</name>
<email>make24@iscas.ac.cn</email>
</author>
<published>2025-09-23T01:36:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b1aabb8ef09b4cf0cc0c92ca9dfd19482f3192c1'/>
<id>b1aabb8ef09b4cf0cc0c92ca9dfd19482f3192c1</id>
<content type='text'>
The fmh_gpib driver contains a device reference count leak in
fmh_gpib_attach_impl() where driver_find_device() increases the
reference count of the device by get_device() when matching but this
reference is not properly decreased. Add put_device() in
fmh_gpib_detach(), which ensures that the reference count of the
device is correctly managed.

Found by code review.

Cc: stable &lt;stable@kernel.org&gt;
Fixes: 8e4841a0888c ("staging: gpib: Add Frank Mori Hess FPGA PCI GPIB driver")
Signed-off-by: Ma Ke &lt;make24@iscas.ac.cn&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The fmh_gpib driver contains a device reference count leak in
fmh_gpib_attach_impl() where driver_find_device() increases the
reference count of the device by get_device() when matching but this
reference is not properly decreased. Add put_device() in
fmh_gpib_detach(), which ensures that the reference count of the
device is correctly managed.

Found by code review.

Cc: stable &lt;stable@kernel.org&gt;
Fixes: 8e4841a0888c ("staging: gpib: Add Frank Mori Hess FPGA PCI GPIB driver")
Signed-off-by: Ma Ke &lt;make24@iscas.ac.cn&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: gpib: Return -EINTR on device clear</title>
<updated>2025-10-13T08:54:44+00:00</updated>
<author>
<name>Dave Penkler</name>
<email>dpenkler@gmail.com</email>
</author>
<published>2025-09-28T11:33:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=aaf2af1ed147ef49be65afb541a67255e9f60d15'/>
<id>aaf2af1ed147ef49be65afb541a67255e9f60d15</id>
<content type='text'>
When the ATN (Attention) line is asserted during a read we get a
NIUSB_ATN_STATE_ERROR during a read. For the controller to send a
device clear it asserts ATN. Normally this is an error but in the case
of a device clear it should be regarded as an interrupt.

Return -EINTR when the Device Clear Active State (DCAS) is entered
else signal an error with dev_dbg with status instead of just dev_err.

Signed-off-by: Dave Penkler &lt;dpenkler@gmail.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When the ATN (Attention) line is asserted during a read we get a
NIUSB_ATN_STATE_ERROR during a read. For the controller to send a
device clear it asserts ATN. Normally this is an error but in the case
of a device clear it should be regarded as an interrupt.

Return -EINTR when the Device Clear Active State (DCAS) is entered
else signal an error with dev_dbg with status instead of just dev_err.

Signed-off-by: Dave Penkler &lt;dpenkler@gmail.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: gpib: Fix sending clear and trigger events</title>
<updated>2025-10-13T08:54:39+00:00</updated>
<author>
<name>Dave Penkler</name>
<email>dpenkler@gmail.com</email>
</author>
<published>2025-09-28T11:33:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=92a2b74a6b5a5d9b076cd9aa75e63c6461cbd073'/>
<id>92a2b74a6b5a5d9b076cd9aa75e63c6461cbd073</id>
<content type='text'>
This driver was not sending device clear or trigger events when the
board entered the DCAS or DTAS state respectively in device mode.

DCAS is the Device Clear Active State which is entered on receiving a
selective device clear message (SDC) or universal device clear message
(DCL) from the controller in charge.

DTAS is the Device Trigger Active State which is entered on receiving
a group execute trigger (GET) message from the controller.

In order for an application, implementing a particular device, to
detect when one of these states is entered the driver needs to send
the appropriate event.

Send the appropriate gpib_event when DCAS or DTAS is set in the
reported status word. This sets the DCAS or DTAS bits in the board's
status word which can be monitored by the application.

Fixes: 4e127de14fa7 ("staging: gpib: Add National Instruments USB GPIB driver")
Cc: stable &lt;stable@kernel.org&gt;
Tested-by: Dave Penkler &lt;dpenkler@gmail.com&gt;
Signed-off-by: Dave Penkler &lt;dpenkler@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This driver was not sending device clear or trigger events when the
board entered the DCAS or DTAS state respectively in device mode.

DCAS is the Device Clear Active State which is entered on receiving a
selective device clear message (SDC) or universal device clear message
(DCL) from the controller in charge.

DTAS is the Device Trigger Active State which is entered on receiving
a group execute trigger (GET) message from the controller.

In order for an application, implementing a particular device, to
detect when one of these states is entered the driver needs to send
the appropriate event.

Send the appropriate gpib_event when DCAS or DTAS is set in the
reported status word. This sets the DCAS or DTAS bits in the board's
status word which can be monitored by the application.

Fixes: 4e127de14fa7 ("staging: gpib: Add National Instruments USB GPIB driver")
Cc: stable &lt;stable@kernel.org&gt;
Tested-by: Dave Penkler &lt;dpenkler@gmail.com&gt;
Signed-off-by: Dave Penkler &lt;dpenkler@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: gpib: Fix no EOI on 1 and 2 byte writes</title>
<updated>2025-10-13T08:53:52+00:00</updated>
<author>
<name>Dave Penkler</name>
<email>dpenkler@gmail.com</email>
</author>
<published>2025-09-28T09:18:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d3c4c1f29aadccf2f43530bfa1e60a6d8030fd4a'/>
<id>d3c4c1f29aadccf2f43530bfa1e60a6d8030fd4a</id>
<content type='text'>
EOI (End Or Identify) is a hardware line on the GPIB bus that can be
asserted with the last byte of a message to indicate the end of the
transfer to the receiving device.

In this driver, a write with send_eoi true is done in 3 parts:
  Send first byte directly
  Send remaining but 1 bytes using the fifo
  Send the last byte directly with EOI asserted

The first byte in a write is always sent by writing to the tms9914
chip directly to setup for the subsequent fifo transfer.  We were not
checking for a 1 byte write with send_eoi true resulting in EOI not
being asserted. Since the fifo transfer was not executed
(fifotransfersize == 0) the retval in the test after the fifo transfer
code was still 1 from the preceding direct write. This caused it to
return without executing the final direct write which would have sent
an unsollicited extra byte.

For a 2 byte message the first byte was sent directly. But since the
fifo transfer was not executed (fifotransfersize == 1) and the retval
in the test after the fifo transfer code was still 1 from the
preceding first byte write it returned before the final direct byte
write with send_eoi true. The second byte was then sent as a separate
1 byte write to complete the 2 byte write count again without EOI
being asserted as above.

Only send the first byte directly if more than 1 byte is to be
transferred with send_eoi true.

Also check for retval &lt; 0 for the error return in case the fifo code
is not used (1 or 2 byte message with send_eoi true).

Fixes: 09a4655ee1eb ("staging: gpib: Add HP/Agilent/Keysight 8235xx PCI GPIB driver")
Cc: stable &lt;stable@kernel.org&gt;
Tested-by: Dave Penkler &lt;dpenkler@gmail.com&gt;
Signed-off-by: Dave Penkler &lt;dpenkler@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
EOI (End Or Identify) is a hardware line on the GPIB bus that can be
asserted with the last byte of a message to indicate the end of the
transfer to the receiving device.

In this driver, a write with send_eoi true is done in 3 parts:
  Send first byte directly
  Send remaining but 1 bytes using the fifo
  Send the last byte directly with EOI asserted

The first byte in a write is always sent by writing to the tms9914
chip directly to setup for the subsequent fifo transfer.  We were not
checking for a 1 byte write with send_eoi true resulting in EOI not
being asserted. Since the fifo transfer was not executed
(fifotransfersize == 0) the retval in the test after the fifo transfer
code was still 1 from the preceding direct write. This caused it to
return without executing the final direct write which would have sent
an unsollicited extra byte.

For a 2 byte message the first byte was sent directly. But since the
fifo transfer was not executed (fifotransfersize == 1) and the retval
in the test after the fifo transfer code was still 1 from the
preceding first byte write it returned before the final direct byte
write with send_eoi true. The second byte was then sent as a separate
1 byte write to complete the 2 byte write count again without EOI
being asserted as above.

Only send the first byte directly if more than 1 byte is to be
transferred with send_eoi true.

Also check for retval &lt; 0 for the error return in case the fifo code
is not used (1 or 2 byte message with send_eoi true).

Fixes: 09a4655ee1eb ("staging: gpib: Add HP/Agilent/Keysight 8235xx PCI GPIB driver")
Cc: stable &lt;stable@kernel.org&gt;
Tested-by: Dave Penkler &lt;dpenkler@gmail.com&gt;
Signed-off-by: Dave Penkler &lt;dpenkler@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'staging-6.18-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging</title>
<updated>2025-10-07T18:41:06+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2025-10-07T18:41:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fbd2e22716d30d77a35affd6493f4bd74fe2e961'/>
<id>fbd2e22716d30d77a35affd6493f4bd74fe2e961</id>
<content type='text'>
Pull staging driver fixes from Greg KH:
 "Here are some staging driver fixes that missed 6.17-final due to my
  travel schedule. They fix a number of reported issues in the axis-fifo
  driver, one of which was just independently discovered by someone else
  today so someone is looking at this code.

  All of these fixes have been in linux-next for many weeks with no
  reported issues"

* tag 'staging-6.18-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging: axis-fifo: flush RX FIFO on read errors
  staging: axis-fifo: fix TX handling on copy_from_user() failure
  staging: axis-fifo: fix maximum TX packet length check
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull staging driver fixes from Greg KH:
 "Here are some staging driver fixes that missed 6.17-final due to my
  travel schedule. They fix a number of reported issues in the axis-fifo
  driver, one of which was just independently discovered by someone else
  today so someone is looking at this code.

  All of these fixes have been in linux-next for many weeks with no
  reported issues"

* tag 'staging-6.18-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging: axis-fifo: flush RX FIFO on read errors
  staging: axis-fifo: fix TX handling on copy_from_user() failure
  staging: axis-fifo: fix maximum TX packet length check
</pre>
</div>
</content>
</entry>
</feed>
