<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/net/can, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/net/can?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/net/can?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-11-07T13:00:27Z</updated>
<entry>
<title>can: j1939: j1939_send_one(): fix missing CAN header initialization</title>
<updated>2022-11-07T13:00:27Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2022-11-04T07:50:00Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=3eb3d283e8579a22b81dd2ac3987b77465b2a22f'/>
<id>urn:sha1:3eb3d283e8579a22b81dd2ac3987b77465b2a22f</id>
<content type='text'>
The read access to struct canxl_frame::len inside of a j1939 created
skbuff revealed a missing initialization of reserved and later filled
elements in struct can_frame.

This patch initializes the 8 byte CAN header with zero.

Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
Cc: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
Link: https://lore.kernel.org/linux-can/20221104052235.GA6474@pengutronix.de
Reported-by: syzbot+d168ec0caca4697e03b1@syzkaller.appspotmail.com
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Link: https://lore.kernel.org/all/20221104075000.105414-1-socketcan@hartkopp.net
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: isotp: fix tx state handling for echo tx processing</title>
<updated>2022-11-07T13:00:27Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2022-11-04T14:25:51Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=866337865f3747c68a3e7bb837611e39cec1ecd6'/>
<id>urn:sha1:866337865f3747c68a3e7bb837611e39cec1ecd6</id>
<content type='text'>
In commit 4b7fe92c0690 ("can: isotp: add local echo tx processing for
consecutive frames") the data flow for consecutive frames (CF) has been
reworked to improve the reliability of long data transfers.

This rework did not touch the transmission and the tx state changes of
single frame (SF) transfers which likely led to the WARN in the
isotp_tx_timer_handler() catching a wrong tx state. This patch makes use
of the improved frame processing for SF frames and sets the ISOTP_SENDING
state in isotp_sendmsg() within the cmpxchg() condition handling.

A review of the state machine and the timer handling additionally revealed
a missing echo timeout handling in the case of the burst mode in
isotp_rcv_echo() and removes a potential timer configuration uncertainty
in isotp_rcv_fc() when the receiver requests consecutive frames.

Fixes: 4b7fe92c0690 ("can: isotp: add local echo tx processing for consecutive frames")
Link: https://lore.kernel.org/linux-can/CAO4mrfe3dG7cMP1V5FLUkw7s+50c9vichigUMQwsxX4M=45QEw@mail.gmail.com/T/#u
Reported-by: Wei Chen &lt;harperchen1110@gmail.com&gt;
Cc: stable@vger.kernel.org # v6.0
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Link: https://lore.kernel.org/all/20221104142551.16924-1-socketcan@hartkopp.net
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: af_can: fix NULL pointer dereference in can_rx_register()</title>
<updated>2022-11-07T12:43:02Z</updated>
<author>
<name>Zhengchao Shao</name>
<email>shaozhengchao@huawei.com</email>
</author>
<published>2022-10-28T08:56:50Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=8aa59e355949442c408408c2d836e561794c40a1'/>
<id>urn:sha1:8aa59e355949442c408408c2d836e561794c40a1</id>
<content type='text'>
It causes NULL pointer dereference when testing as following:
(a) use syscall(__NR_socket, 0x10ul, 3ul, 0) to create netlink socket.
(b) use syscall(__NR_sendmsg, ...) to create bond link device and vxcan
    link device, and bind vxcan device to bond device (can also use
    ifenslave command to bind vxcan device to bond device).
(c) use syscall(__NR_socket, 0x1dul, 3ul, 1) to create CAN socket.
(d) use syscall(__NR_bind, ...) to bind the bond device to CAN socket.

The bond device invokes the can-raw protocol registration interface to
receive CAN packets. However, ml_priv is not allocated to the dev,
dev_rcv_lists is assigned to NULL in can_rx_register(). In this case,
it will occur the NULL pointer dereference issue.

The following is the stack information:
BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 122a4067 P4D 122a4067 PUD 1223c067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
RIP: 0010:can_rx_register+0x12d/0x1e0
Call Trace:
&lt;TASK&gt;
raw_enable_filters+0x8d/0x120
raw_enable_allfilters+0x3b/0x130
raw_bind+0x118/0x4f0
__sys_bind+0x163/0x1a0
__x64_sys_bind+0x1e/0x30
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
&lt;/TASK&gt;

Fixes: 4e096a18867a ("net: introduce CAN specific pointer in the struct net_device")
Signed-off-by: Zhengchao Shao &lt;shaozhengchao@huawei.com&gt;
Reviewed-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Link: https://lore.kernel.org/all/20221028085650.170470-1-shaozhengchao@huawei.com
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: af_can: can_exit(): add missing dev_remove_pack() of canxl_packet</title>
<updated>2022-11-07T12:43:02Z</updated>
<author>
<name>Chen Zhongjin</name>
<email>chenzhongjin@huawei.com</email>
</author>
<published>2022-10-31T03:30:53Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=a3335faebe1608f3e78e24f09501c9f7d5ebf87a'/>
<id>urn:sha1:a3335faebe1608f3e78e24f09501c9f7d5ebf87a</id>
<content type='text'>
In can_init(), dev_add_pack(&amp;canxl_packet) is added but not removed in
can_exit(). It breaks the packet handler list and can make kernel
panic when can_init() is called for the second time.

| &gt; modprobe can &amp;&amp; rmmod can
| &gt; rmmod xxx &amp;&amp; modprobe can
|
| BUG: unable to handle page fault for address: fffffbfff807d7f4
| RIP: 0010:dev_add_pack+0x133/0x1f0
| Call Trace:
|  &lt;TASK&gt;
|  can_init+0xaa/0x1000 [can]
|  do_one_initcall+0xd3/0x4e0
|  ...

Fixes: fb08cba12b52 ("can: canxl: update CAN infrastructure for CAN XL frames")
Signed-off-by: Chen Zhongjin &lt;chenzhongjin@huawei.com&gt;
Acked-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Link: https://lore.kernel.org/all/20221031033053.37849-1-chenzhongjin@huawei.com
[mkl: adjust subject and commit message]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: j1939: transport: j1939_session_skb_drop_old(): spin_unlock_irqrestore() before kfree_skb()</title>
<updated>2022-10-27T11:34:23Z</updated>
<author>
<name>Yang Yingliang</name>
<email>yangyingliang@huawei.com</email>
</author>
<published>2022-10-27T09:12:37Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=c3c06c61890da80494bb196f75d89b791adda87f'/>
<id>urn:sha1:c3c06c61890da80494bb196f75d89b791adda87f</id>
<content type='text'>
It is not allowed to call kfree_skb() from hardware interrupt context
or with interrupts being disabled. The skb is unlinked from the queue,
so it can be freed after spin_unlock_irqrestore().

Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
Signed-off-by: Yang Yingliang &lt;yangyingliang@huawei.com&gt;
Acked-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
Link: https://lore.kernel.org/all/20221027091237.2290111-1-yangyingliang@huawei.com
Cc: stable@vger.kernel.org
[mkl: adjust subject]
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: bcm: check the result of can_send() in bcm_can_tx()</title>
<updated>2022-09-23T11:53:10Z</updated>
<author>
<name>Ziyang Xuan</name>
<email>william.xuanziyang@huawei.com</email>
</author>
<published>2022-09-15T01:55:56Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=3fd7bfd28cfd68ae80a2fe92ea1615722cc2ee6e'/>
<id>urn:sha1:3fd7bfd28cfd68ae80a2fe92ea1615722cc2ee6e</id>
<content type='text'>
If can_send() fail, it should not update frames_abs counter
in bcm_can_tx(). Add the result check for can_send() in bcm_can_tx().

Suggested-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Suggested-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Ziyang Xuan &lt;william.xuanziyang@huawei.com&gt;
Link: https://lore.kernel.org/all/9851878e74d6d37aee2f1ee76d68361a46f89458.1663206163.git.william.xuanziyang@huawei.com
Acked-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: bcm: registration process optimization in bcm_module_init()</title>
<updated>2022-09-23T11:53:02Z</updated>
<author>
<name>Ziyang Xuan</name>
<email>william.xuanziyang@huawei.com</email>
</author>
<published>2022-09-15T01:55:55Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=edd1a7e42f1d2d09c5f79ecef05ae19dc669bf34'/>
<id>urn:sha1:edd1a7e42f1d2d09c5f79ecef05ae19dc669bf34</id>
<content type='text'>
Now, register_netdevice_notifier() and register_pernet_subsys() are both
after can_proto_register(). It can create CAN_BCM socket and process socket
once can_proto_register() successfully, so it is possible missing notifier
event or proc node creation because notifier or bcm proc directory is not
registered or created yet. Although this is a low probability scenario, it
is not impossible.

Move register_pernet_subsys() and register_netdevice_notifier() to the
front of can_proto_register(). In addition, register_pernet_subsys() and
register_netdevice_notifier() may fail, check their results are necessary.

Signed-off-by: Ziyang Xuan &lt;william.xuanziyang@huawei.com&gt;
Link: https://lore.kernel.org/all/823cff0ebec33fa9389eeaf8b8ded3217c32cb38.1663206163.git.william.xuanziyang@huawei.com
Acked-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: raw: add CAN XL support</title>
<updated>2022-09-15T07:08:09Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2022-09-12T17:07:25Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=626332696d7506e8f844a564277bdba2dc78fcb5'/>
<id>urn:sha1:626332696d7506e8f844a564277bdba2dc78fcb5</id>
<content type='text'>
Enable CAN_RAW sockets to read and write CAN XL frames analogue to the
CAN FD extension (new CAN_RAW_XL_FRAMES sockopt).

A CAN XL network interface is capable to handle Classical CAN, CAN FD and
CAN XL frames. When CAN_RAW_XL_FRAMES is enabled, the CAN_RAW socket checks
whether the addressed CAN network interface is capable to handle the
provided CAN frame.

In opposite to the fixed number of bytes for
- CAN frames (CAN_MTU = sizeof(struct can_frame))
- CAN FD frames (CANFD_MTU = sizeof(struct can_frame))
the number of bytes when reading/writing CAN XL frames depends on the
number of data bytes. For efficiency reasons the length of the struct
canxl_frame is truncated to the needed size for read/write operations.
This leads to a calculated size of CANXL_HDR_SIZE + canxl_frame::len which
is enforced on write() operations and guaranteed on read() operations.

NB: Valid length values are 1 .. 2048 (CANXL_MIN_DLEN .. CANXL_MAX_DLEN).

Acked-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Link: https://lore.kernel.org/all/20220912170725.120748-8-socketcan@hartkopp.net
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: canxl: update CAN infrastructure for CAN XL frames</title>
<updated>2022-09-15T07:08:09Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2022-09-12T17:07:23Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=fb08cba12b52cba4366e858932307649dc5304e2'/>
<id>urn:sha1:fb08cba12b52cba4366e858932307649dc5304e2</id>
<content type='text'>
- add new ETH_P_CANXL ethernet protocol type
- update skb checks for CAN XL
- add alloc_canxl_skb() which now needs a data length parameter
- introduce init_can_skb_reserve() to reduce code duplication

Acked-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Link: https://lore.kernel.org/all/20220912170725.120748-6-socketcan@hartkopp.net
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: set CANFD_FDF flag in all CAN FD frame structures</title>
<updated>2022-09-15T07:08:08Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2022-09-12T17:07:21Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=061834624c87282c6d9d8c5395aaff4380e5e1fc'/>
<id>urn:sha1:061834624c87282c6d9d8c5395aaff4380e5e1fc</id>
<content type='text'>
To simplify the testing in user space all struct canfd_frame's provided by
the CAN subsystem of the Linux kernel now have the CANFD_FDF flag set in
canfd_frame::flags.

NB: Handcrafted ETH_P_CANFD frames introduced via PF_PACKET socket might
not set this bit correctly. During the check for sufficient headroom in
PF_PACKET sk_buffs the uninitialized CAN sk_buff data structures are filled.
In the case of a CAN FD frame the CANFD_FDF flag is set accordingly.

As the CAN frame content is already zero initialized in alloc_canfd_skb()
the obsolete initialization of cf-&gt;flags in the CTU CAN FD driver has been
removed as it would overwrite the already set CANFD_FDF flag.

Acked-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Link: https://lore.kernel.org/all/20220912170725.120748-4-socketcan@hartkopp.net
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
</feed>
