lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 01 Jan 2014 22:23:23 -0500 (EST) From: David Miller <davem@...emloft.net> To: dborkman@...hat.com Cc: netdev@...r.kernel.org, acme@...stprotocols.net, stephen@...workplumber.org Subject: Re: [PATCH net] net: llc: fix order of evaluation in llc_conn_ac_inc_vr_by_1 From: Daniel Borkmann <dborkman@...hat.com> Date: Wed, 1 Jan 2014 23:04:25 +0100 > 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@...hat.com> Applied, thanks Daniel. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists