summaryrefslogtreecommitdiff
path: root/kernel/sysctl_binary.c
diff options
context:
space:
mode:
authorNicolai Stange <nstange@suse.de>2018-01-08 15:54:44 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2020-05-02 17:20:29 +0200
commit1a3bb8e0f826844db633e17998abd31f1f7bafde (patch)
tree85832729f2175de7144a15595b88ca18aa8b9997 /kernel/sysctl_binary.c
parentd0cd27b282dcb426b4b9aeba409e03efe460fd4c (diff)
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>
Diffstat (limited to 'kernel/sysctl_binary.c')
0 files changed, 0 insertions, 0 deletions