archive mirror
 help / color / mirror / Atom feed
From: Vincent MAILHOL <>
To: Oliver Hartkopp <>
Cc: Marc Kleine-Budde <>,
	linux-can <>
Subject: Re: [PATCH v3 1/2] can: netlink: prevent incoherent can configuration in case of early return
Date: Tue, 14 Sep 2021 18:35:31 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Oliver,

On Wed. 8 sep. 2021 at 20:41, Oliver Hartkopp <> wrote:
> - nextdev ML
> - linux-kernel ML
> Hi Vincent,
> On 07.09.21 14:51, Vincent MAILHOL wrote:
> > On Tue. 7 Sep. 2021 at 01:03, Vincent Mailhol
> > <> wrote:
> >> struct can_priv has a set of flags (can_priv::ctrlmode) which are
> >> correlated with the other fields of the structure. In
> >> can_changelink(), those flags are set first and copied to can_priv. If
> >> the function has to return early, for example due to an out of range
> >> value provided by the user, then the global configuration might become
> >> incoherent.
> >>
> >> Example: the user provides an out of range dbitrate (e.g. 20
> >> Mbps). The command fails (-EINVAL), however the FD flag was already
> >> set resulting in a configuration where FD is on but the databittiming
> >> parameters are empty.
> When the ip configuration fails you get an error code. And you
> *typically* do it again to fix your wrong command line parameters.
> ¯\_(ツ)_/¯

Overall yes. I tried to think of a counterexample and the best I
could think of is if the user does:
# ip link set can0 type can bitrate 500000 dbitrate 20000000 fd on; ip
link set can0 up

In which case, the .ndo_open() function of the driver would be
triggered with incorrect parameters.

> If not the attempt to set the CAN interface to 'up' will fail (as the
> last line of defense).

Mostly correct: open_candev() will spot that the data bitrate is not set
making the .ndo_open() fails as long as the driver correctly
checks open_candev() return value.

However, one driver fails to check the return value of open_candev():

So, for this particular driver, we can send incoherent values to the device.

> The code with all the sanity checks is already pretty complex IMO.


> I wonder if this effort is worth it.

Well, I was thinking "this is a bug so let's fix it". But your
argument is fair. I also did not like how complex the code was
getting when trying to fix that. I guess that this bug is
acceptable. I will leave it as it is.

Now, I am just worried about the softing driver.


Yours sincerely,

  reply	other threads:[~2021-09-14  9:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-06 16:03 [PATCH v3 0/2] prevent incoherent can configuration in case of early return in the CAN netlink interface Vincent Mailhol
2021-09-06 16:03 ` [PATCH v3 1/2] can: netlink: prevent incoherent can configuration in case of early return Vincent Mailhol
2021-09-07  2:05   ` Vincent MAILHOL
2021-09-07 12:51   ` Vincent MAILHOL
2021-09-08 11:41     ` Oliver Hartkopp
2021-09-14  9:35       ` Vincent MAILHOL [this message]
2021-09-14 11:45         ` Vincent MAILHOL
2021-09-14 12:13           ` Oliver Hartkopp
2021-09-06 16:03 ` [PATCH v3 2/2] can: bittiming: change can_calc_tdco()'s prototype to not directly modify priv Vincent Mailhol

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).