On 1/4/19 10:13 AM, Oliver Hartkopp wrote:
> Muyu Yu provided a POC where user root with CAP_NET_ADMIN can create a CAN
> frame modification rule that makes the data length code a higher value than
> the available CAN frame data size. In combination with a configured checksum
> calculation where th
Hi all,
just for the records:
I did some tests with the cangw tool from
https://github.com/linux-can/can-utils where I removed some sanity
checks (6,7) in parse_mod() to be able to reproduce Muyu's setup.
The filters are configured as follows:
# cangw -L
cangw -A -s vcan0 -d vcan1 -e -m SET
On 1/4/19 11:31 AM, Michal Kubecek wrote:
On Fri, Jan 04, 2019 at 10:13:53AM +0100, Oliver Hartkopp wrote:
Muyu Yu provided a POC where user root with CAP_NET_ADMIN can create a CAN
frame modification rule that makes the data length code a higher value than
the available CAN frame data size.
On Fri, Jan 04, 2019 at 10:13:53AM +0100, Oliver Hartkopp wrote:
> Muyu Yu provided a POC where user root with CAP_NET_ADMIN can create a CAN
> frame modification rule that makes the data length code a higher value than
> the available CAN frame data size. In combination with a configured checksum
Hi Michal,
On 1/4/19 10:01 AM, Michal Kubecek wrote:
On Thu, Jan 03, 2019 at 10:03:47PM +0100, Oliver Hartkopp wrote:
1. I'm still using the test "if (cf->can_dlc > 8)" with a proper comment as
CAN_MAX_DLC and CAN_MAX_DLEN are not defined in Linux stable 3.2 - so that
we can apply the patch to
Muyu Yu provided a POC where user root with CAP_NET_ADMIN can create a CAN
frame modification rule that makes the data length code a higher value than
the available CAN frame data size. In combination with a configured checksum
calculation where the result is stored relatively to the end of the dat
On Thu, Jan 03, 2019 at 10:03:47PM +0100, Oliver Hartkopp wrote:
> 1. I'm still using the test "if (cf->can_dlc > 8)" with a proper comment as
> CAN_MAX_DLC and CAN_MAX_DLEN are not defined in Linux stable 3.2 - so that
> we can apply the patch to all versions of gw.c
I may be biased as substantia
Hi Michal,
On 1/3/19 9:33 PM, Michal Kubecek wrote:
On Thu, Jan 03, 2019 at 08:31:51PM +0100, Oliver Hartkopp wrote:
Anyway your modification makes definitely sense, as it allows to process CAN
FD frames in struct canfd_frame as long as only data is modified that is
also available in a struct
On Thu, Jan 03, 2019 at 08:31:51PM +0100, Oliver Hartkopp wrote:
> Hi Michal,
>
> On 1/3/19 3:01 PM, Michal Kubecek wrote:
> > On Thu, Jan 03, 2019 at 01:26:34PM +0100, Oliver Hartkopp wrote:
> (..)
> > > /* check for checksum updates when the CAN frame has been
> > > modified */
> > >
Hi Michal,
On 1/3/19 3:01 PM, Michal Kubecek wrote:
On Thu, Jan 03, 2019 at 01:26:34PM +0100, Oliver Hartkopp wrote:
(..)
/* check for checksum updates when the CAN frame has been modified */
if (modidx) {
+ /* ensure DLC boundaries after the different mods */
+
On Thu, Jan 03, 2019 at 01:26:34PM +0100, Oliver Hartkopp wrote:
> The CAN frame modification rules allow bitwise logical operations which can
> be also applied to the can_dlc field. Ensure the manipulation result to
> maintain the can_dlc boundaries so that the CAN drivers do not accidently
> writ
The CAN frame modification rules allow bitwise logical operations which can
be also applied to the can_dlc field. Ensure the manipulation result to
maintain the can_dlc boundaries so that the CAN drivers do not accidently
write arbitrary content beyond the data registers in the CAN controllers
I/O
12 matches
Mail list logo
