net: llc: fix order of evaluation in llc_conn_ac_inc_vr_by_1
authorDaniel Borkmann <dborkman@redhat.com>
Wed, 1 Jan 2014 22:04:25 +0000 (23:04 +0100)
committerDavid S. Miller <davem@davemloft.net>
Thu, 2 Jan 2014 03:22:43 +0000 (22:22 -0500)
commit7e0309631ecf0cd16edba72ff74747fa1b96ead3
treefe37d9bc3d10e8a576e4d36418cf6c0e882588db
parentf17e9fa5686ac21bce756638ef71160395880928
net: llc: fix order of evaluation in llc_conn_ac_inc_vr_by_1

Function llc_conn_ac_inc_vr_by_1() evaluates via macro
PDU_GET_NEXT_Vr() into ...

  llc_sk(sk)->vR = ++llc_sk(sk)->vR & 0xffffffffffffff7f

... but the order in which the side effects take place is
undefined because there is no intervening sequence point.

As llc_sk(sk)->vR is written in llc_sk(sk)->vR (assignment
left-hand side) and written in ++llc_sk(sk)->vR & 0xffffffffffffff7f
this might possibly yield undefined behavior.

The final value of llc_sk(sk)->vR is ambiguous, because,
depending on the order of expression evaluation, the
increment may occur before, after, or interleaved with
the assignment. In C, evaluating such an expression yields
undefined behavior.

Since we're doing the increment via PDU_GET_NEXT_Vr() macro
and the only place it is being used is from
llc_conn_ac_inc_vr_by_1(), in order to increment vR by 1
with a follow-up optimized modulo, rewrite the expression
into ((vR + 1) & CONST) in order to fix this.

Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
include/net/llc_pdu.h