<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/can, branch v6.13.6</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.13.6</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.13.6'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-02-21T13:11:04+00:00</updated>
<entry>
<title>can: etas_es58x: fix potential NULL pointer dereference on udev-&gt;serial</title>
<updated>2025-02-21T13:11:04+00:00</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2025-02-04T15:48:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5059ea98d7bc133903d3e47ab36df6ed11d0c95f'/>
<id>urn:sha1:5059ea98d7bc133903d3e47ab36df6ed11d0c95f</id>
<content type='text'>
commit a1ad2109ce41c9e3912dadd07ad8a9c640064ffb upstream.

The driver assumed that es58x_dev-&gt;udev-&gt;serial could never be NULL.
While this is true on commercially available devices, an attacker
could spoof the device identity providing a NULL USB serial number.
That would trigger a NULL pointer dereference.

Add a check on es58x_dev-&gt;udev-&gt;serial before accessing it.

Reported-by: yan kang &lt;kangyan91@outlook.com&gt;
Reported-by: yue sun &lt;samsun1006219@gmail.com&gt;
Closes: https://lore.kernel.org/linux-can/SY8P300MB0421E0013C0EBD2AA46BA709A1F42@SY8P300MB0421.AUSP300.PROD.OUTLOOK.COM/
Fixes: 9f06631c3f1f ("can: etas_es58x: export product information through devlink_ops::info_get()")
Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://patch.msgid.link/20250204154859.9797-2-mailhol.vincent@wanadoo.fr
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>can: rockchip: rkcanfd_handle_rx_fifo_overflow_int(): bail out if skb cannot be allocated</title>
<updated>2025-02-21T13:11:04+00:00</updated>
<author>
<name>Robin van der Gracht</name>
<email>robin@protonic.nl</email>
</author>
<published>2025-01-27T12:16:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=946750e7865df2e70045071051abf768785dd570'/>
<id>urn:sha1:946750e7865df2e70045071051abf768785dd570</id>
<content type='text'>
commit f7f0adfe64de08803990dc4cbecd2849c04e314a upstream.

Fix NULL pointer check in rkcanfd_handle_rx_fifo_overflow_int() to
bail out if skb cannot be allocated.

Fixes: ff60bfbaf67f ("can: rockchip_canfd: add driver for Rockchip CAN-FD controller")
Cc: stable@vger.kernel.org
Signed-off-by: Robin van der Gracht &lt;robin@protonic.nl&gt;
Link: https://patch.msgid.link/20250208-fix-rockchip-canfd-v1-1-ec533c8a9895@pengutronix.de
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>can: c_can: fix unbalanced runtime PM disable in error path</title>
<updated>2025-02-21T13:11:04+00:00</updated>
<author>
<name>Krzysztof Kozlowski</name>
<email>krzysztof.kozlowski@linaro.org</email>
</author>
<published>2025-01-12T12:41:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ee9abeeaab6a979b1115d52b7c1097ff39e7482d'/>
<id>urn:sha1:ee9abeeaab6a979b1115d52b7c1097ff39e7482d</id>
<content type='text'>
commit 257a2cd3eb578ee63d6bf90475dc4f4b16984139 upstream.

Runtime PM is enabled as one of the last steps of probe(), so all
earlier gotos to "exit_free_device" label were not correct and were
leading to unbalanced runtime PM disable depth.

Fixes: 6e2fe01dd6f9 ("can: c_can: move runtime PM enable/disable to c_can_platform")
Cc: stable@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@linaro.org&gt;
Reviewed-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://patch.msgid.link/20250112-syscon-phandle-args-can-v1-1-314d9549906f@linaro.org
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>can: ctucanfd: handle skb allocation failure</title>
<updated>2025-02-21T13:11:04+00:00</updated>
<author>
<name>Fedor Pchelkin</name>
<email>pchelkin@ispras.ru</email>
</author>
<published>2025-01-14T15:21:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e7e2e2318b1f085044126ba553a4e619842fc36d'/>
<id>urn:sha1:e7e2e2318b1f085044126ba553a4e619842fc36d</id>
<content type='text'>
commit 9bd24927e3eeb85642c7baa3b28be8bea6c2a078 upstream.

If skb allocation fails, the pointer to struct can_frame is NULL. This
is actually handled everywhere inside ctucan_err_interrupt() except for
the only place.

Add the missed NULL check.

Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.

Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.")
Cc: stable@vger.kernel.org
Signed-off-by: Fedor Pchelkin &lt;pchelkin@ispras.ru&gt;
Acked-by: Pavel Pisa &lt;pisa@cmp.felk.cvut.cz&gt;
Reviewed-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Link: https://patch.msgid.link/20250114152138.139580-1-pchelkin@ispras.ru
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>can: m_can: fix missed interrupts with m_can_pci</title>
<updated>2024-12-18T08:30:52+00:00</updated>
<author>
<name>Matthias Schiffer</name>
<email>matthias.schiffer@ew.tq-group.com</email>
</author>
<published>2024-10-07T08:23:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=743375f8deee360b0e902074bab99b0c9368d42f'/>
<id>urn:sha1:743375f8deee360b0e902074bab99b0c9368d42f</id>
<content type='text'>
The interrupt line of PCI devices is interpreted as edge-triggered,
however the interrupt signal of the m_can controller integrated in Intel
Elkhart Lake CPUs appears to be generated level-triggered.

Consider the following sequence of events:

- IR register is read, interrupt X is set
- A new interrupt Y is triggered in the m_can controller
- IR register is written to acknowledge interrupt X. Y remains set in IR

As at no point in this sequence no interrupt flag is set in IR, the
m_can interrupt line will never become deasserted, and no edge will ever
be observed to trigger another run of the ISR. This was observed to
result in the TX queue of the EHL m_can to get stuck under high load,
because frames were queued to the hardware in m_can_start_xmit(), but
m_can_finish_tx() was never run to account for their successful
transmission.

On an Elkhart Lake based board with the two CAN interfaces connected to
each other, the following script can reproduce the issue:

    ip link set can0 up type can bitrate 1000000
    ip link set can1 up type can bitrate 1000000

    cangen can0 -g 2 -I 000 -L 8 &amp;
    cangen can0 -g 2 -I 001 -L 8 &amp;
    cangen can0 -g 2 -I 002 -L 8 &amp;
    cangen can0 -g 2 -I 003 -L 8 &amp;
    cangen can0 -g 2 -I 004 -L 8 &amp;
    cangen can0 -g 2 -I 005 -L 8 &amp;
    cangen can0 -g 2 -I 006 -L 8 &amp;
    cangen can0 -g 2 -I 007 -L 8 &amp;

    cangen can1 -g 2 -I 100 -L 8 &amp;
    cangen can1 -g 2 -I 101 -L 8 &amp;
    cangen can1 -g 2 -I 102 -L 8 &amp;
    cangen can1 -g 2 -I 103 -L 8 &amp;
    cangen can1 -g 2 -I 104 -L 8 &amp;
    cangen can1 -g 2 -I 105 -L 8 &amp;
    cangen can1 -g 2 -I 106 -L 8 &amp;
    cangen can1 -g 2 -I 107 -L 8 &amp;

    stress-ng --matrix 0 &amp;

To fix the issue, repeatedly read and acknowledge interrupts at the
start of the ISR until no interrupt flags are set, so the next incoming
interrupt will also result in an edge on the interrupt line.

While we have received a report that even with this patch, the TX queue
can become stuck under certain (currently unknown) circumstances on the
Elkhart Lake, this patch completely fixes the issue with the above
reproducer, and it is unclear whether the remaining issue has a similar
cause at all.

Fixes: cab7ffc0324f ("can: m_can: add PCI glue driver for Intel Elkhart Lake")
Signed-off-by: Matthias Schiffer &lt;matthias.schiffer@ew.tq-group.com&gt;
Reviewed-by: Markus Schneider-Pargmann &lt;msp@baylibre.com&gt;
Link: https://patch.msgid.link/fdf0439c51bcb3a46c21e9fb21c7f1d06363be84.1728288535.git.matthias.schiffer@ew.tq-group.com
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: m_can: set init flag earlier in probe</title>
<updated>2024-12-18T08:30:52+00:00</updated>
<author>
<name>Matthias Schiffer</name>
<email>matthias.schiffer@ew.tq-group.com</email>
</author>
<published>2024-10-07T08:23:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fca2977629f49dee437e217c3fc423b6e0cad98c'/>
<id>urn:sha1:fca2977629f49dee437e217c3fc423b6e0cad98c</id>
<content type='text'>
While an m_can controller usually already has the init flag from a
hardware reset, no such reset happens on the integrated m_can_pci of the
Intel Elkhart Lake. If the CAN controller is found in an active state,
m_can_dev_setup() would fail because m_can_niso_supported() calls
m_can_cccr_update_bits(), which refuses to modify any other configuration
bits when CCCR_INIT is not set.

To avoid this issue, set CCCR_INIT before attempting to modify any other
configuration flags.

Fixes: cd5a46ce6fa6 ("can: m_can: don't enable transceiver when probing")
Signed-off-by: Matthias Schiffer &lt;matthias.schiffer@ew.tq-group.com&gt;
Reviewed-by: Markus Schneider-Pargmann &lt;msp@baylibre.com&gt;
Link: https://patch.msgid.link/e247f331cb72829fcbdfda74f31a59cbad1a6006.1728288535.git.matthias.schiffer@ew.tq-group.com
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>rtnetlink: fix double call of rtnl_link_get_net_ifla()</title>
<updated>2024-12-03T10:29:29+00:00</updated>
<author>
<name>Cong Wang</name>
<email>cong.wang@bytedance.com</email>
</author>
<published>2024-11-29T21:25:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=48327566769a6ff2e873b6bf075392bd756625ca'/>
<id>urn:sha1:48327566769a6ff2e873b6bf075392bd756625ca</id>
<content type='text'>
Currently rtnl_link_get_net_ifla() gets called twice when we create
peer devices, once in rtnl_add_peer_net() and once in each -&gt;newlink()
implementation.

This looks safer, however, it leads to a classic Time-of-Check to
Time-of-Use (TOCTOU) bug since IFLA_NET_NS_PID is very dynamic. And
because of the lack of checking error pointer of the second call, it
also leads to a kernel crash as reported by syzbot.

Fix this by getting rid of the second call, which already becomes
redudant after Kuniyuki's work. We have to propagate the result of the
first rtnl_link_get_net_ifla() down to each -&gt;newlink().

Reported-by: syzbot+21ba4d5adff0b6a7cfc6@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=21ba4d5adff0b6a7cfc6
Fixes: 0eb87b02a705 ("veth: Set VETH_INFO_PEER to veth_link_ops.peer_type.")
Fixes: 6b84e558e95d ("vxcan: Set VXCAN_INFO_PEER to vxcan_link_ops.peer_type.")
Fixes: fefd5d082172 ("netkit: Set IFLA_NETKIT_PEER_INFO to netkit_link_ops.peer_type.")
Cc: Kuniyuki Iwashima &lt;kuniyu@amazon.com&gt;
Signed-off-by: Cong Wang &lt;cong.wang@bytedance.com&gt;
Reviewed-by: Kuniyuki Iwashima &lt;kuniyu@amazon.com&gt;
Link: https://patch.msgid.link/20241129212519.825567-1-xiyou.wangcong@gmail.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;

</content>
</entry>
<entry>
<title>can: mcp251xfd: mcp251xfd_get_tef_len(): work around erratum DS80000789E 6.</title>
<updated>2024-11-26T10:42:32+00:00</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2024-11-24T17:42:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=30447a1bc0e066e492552b3e5ffeb63c1605dfe2'/>
<id>urn:sha1:30447a1bc0e066e492552b3e5ffeb63c1605dfe2</id>
<content type='text'>
Commit b8e0ddd36ce9 ("can: mcp251xfd: tef: prepare to workaround
broken TEF FIFO tail index erratum") introduced
mcp251xfd_get_tef_len() to get the number of unhandled transmit events
from the Transmit Event FIFO (TEF).

As the TEF has no head index, the driver uses the TX-FIFO's tail index
instead, assuming that send frames are completed.

When calculating the number of unhandled TEF events, that commit
didn't take mcp2518fd erratum DS80000789E 6. into account. According
to that erratum, the FIFOCI bits of a FIFOSTA register, here the
TX-FIFO tail index might be corrupted.

However here it seems the bit indicating that the TX-FIFO is
empty (MCP251XFD_REG_FIFOSTA_TFERFFIF) is not correct while the
TX-FIFO tail index is.

Assume that the TX-FIFO is indeed empty if:
- Chip's head and tail index are equal (len == 0).
- The TX-FIFO is less than half full.
  (The TX-FIFO empty case has already been checked at the
   beginning of this function.)
- No free buffers in the TX ring.

If the TX-FIFO is assumed to be empty, assume that the TEF is full and
return the number of elements in the TX-FIFO (which equals the number
of TEF elements).

If these assumptions are false, the driver might read to many objects
from the TEF. mcp251xfd_handle_tefif_one() checks the sequence numbers
and will refuse to process old events.

Reported-by: Renjaya Raga Zenta &lt;renjaya.zenta@formulatrix.com&gt;
Closes: https://patch.msgid.link/CAJ7t6HgaeQ3a_OtfszezU=zB-FqiZXqrnATJ3UujNoQJJf7GgA@mail.gmail.com
Fixes: b8e0ddd36ce9 ("can: mcp251xfd: tef: prepare to workaround broken TEF FIFO tail index erratum")
Tested-by: Renjaya Raga Zenta &lt;renjaya.zenta@formulatrix.com&gt;
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20241126-mcp251xfd-fix-length-calculation-v2-1-c2ed516ed6ba@pengutronix.de
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: f81604: f81604_handle_can_bus_errors(): fix {rx,tx}_errors statistics</title>
<updated>2024-11-26T09:51:12+00:00</updated>
<author>
<name>Dario Binacchi</name>
<email>dario.binacchi@amarulasolutions.com</email>
</author>
<published>2024-11-22T22:15:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d7b916540c2ba3d2a88c27b2a6287b39d8eac052'/>
<id>urn:sha1:d7b916540c2ba3d2a88c27b2a6287b39d8eac052</id>
<content type='text'>
The f81604_handle_can_bus_errors() function only incremented the receive
error counter and never the transmit error counter, even if the ECC_DIR
flag reported that an error had occurred during transmission.

Increment the receive/transmit error counter based on the value of the
ECC_DIR flag.

Fixes: 88da17436973 ("can: usb: f81604: add Fintek F81604 support")
Signed-off-by: Dario Binacchi &lt;dario.binacchi@amarulasolutions.com&gt;
Link: https://patch.msgid.link/20241122221650.633981-13-dario.binacchi@amarulasolutions.com
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: ems_usb: ems_usb_rx_err(): fix {rx,tx}_errors statistics</title>
<updated>2024-11-26T09:51:06+00:00</updated>
<author>
<name>Dario Binacchi</name>
<email>dario.binacchi@amarulasolutions.com</email>
</author>
<published>2024-11-22T22:15:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=72a7e2e74b3075959f05e622bae09b115957dffe'/>
<id>urn:sha1:72a7e2e74b3075959f05e622bae09b115957dffe</id>
<content type='text'>
The ems_usb_rx_err() function only incremented the receive error counter
and never the transmit error counter, even if the ECC_DIR flag reported
that an error had occurred during transmission.

Increment the receive/transmit error counter based on the value of the
ECC_DIR flag.

Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface")
Signed-off-by: Dario Binacchi &lt;dario.binacchi@amarulasolutions.com&gt;
Link: https://patch.msgid.link/20241122221650.633981-12-dario.binacchi@amarulasolutions.com
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
</feed>
