Nicolai Stange 1a3bb8e0f8 net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()
commit 20b50d79974ea3192e8c3ab7faf4e536e5f14d8f upstream.

Commit 8f659a03a0ba ("net: ipv4: fix for a race condition in
raw_sendmsg") fixed the issue of possibly inconsistent ->hdrincl handling
due to concurrent updates by reading this bit-field member into a local
variable and using the thus stabilized value in subsequent tests.

However, aforementioned commit also adds the (correct) comment that

  /* hdrincl should be READ_ONCE(inet->hdrincl)
   * but READ_ONCE() doesn't work with bit fields
   */

because as it stands, the compiler is free to shortcut or even eliminate
the local variable at its will.

Note that I have not seen anything like this happening in reality and thus,
the concern is a theoretical one.

However, in order to be on the safe side, emulate a READ_ONCE() on the
bit-field by doing it on the local 'hdrincl' variable itself:

	int hdrincl = inet->hdrincl;
	hdrincl = READ_ONCE(hdrincl);

This breaks the chain in the sense that the compiler is not allowed
to replace subsequent reads from hdrincl with reloads from inet->hdrincl.

Fixes: 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg")
Signed-off-by: Nicolai Stange <nstange@suse.de>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-02 17:20:29 +02:00
..
2019-12-05 15:27:07 +01:00
2020-04-02 19:02:34 +02:00
2019-09-16 08:13:35 +02:00
2015-10-07 04:27:43 -07:00
2019-06-22 08:18:25 +02:00
2019-03-23 08:44:34 +01:00
2019-11-28 18:25:43 +01:00
2020-01-29 10:21:53 +01:00
2019-01-13 10:05:28 +01:00
2018-02-25 11:03:37 +01:00
2020-01-23 08:18:37 +01:00