~kamalmostafa/ubuntu/+source/linux/+git/trusty:fix-stackprotector
- Git
- lp:~kamalmostafa/ubuntu/+source/linux/+git/trusty
- fix-stackprotector
- Get this branch:
-
git clone
-b fix-stackprotector
https://git.launchpad.net/~kamalmostafa/ubuntu/+source/linux/+git/trusty
Branch merges
Related source package recipes
Branch information
- Name:
- fix-stackprotector
Recent commits
- 9d85c82... by Kamal Mostafa
-
Revert "UBUNTU: SAUCE: disable stack-protector for ARM compressed bootloader"
This reverts commit 900be9e1bdc70f0
8ee67326254e1f3 40fba09541. This SAUCE is no longer needed, since these commits fix the broken
stack-protector logic in arch/arm/Makefile:stackprotector: Introduce CONFIG_
CC_STACKPROTECT OR_STRONG
stackprotector: Unify the HAVE_CC_STACKPROTECTOR logic between architectures Signed-off-by: Kamal Mostafa <email address hidden>
- 30db1cd... by Kamal Mostafa
-
UBUNTU: [Config] updateconfigs: select CC_STACKPROTECT
OR_REGULAR Signed-off-by: Kamal Mostafa <email address hidden>
- bdd16f9... by Kees Cook
-
stackprotector: Introduce CONFIG_
CC_STACKPROTECT OR_STRONG commit 8779657d29c0ebc
c0c94ede4df2f49 7baf1b563f upstream. This changes the stack protector config option into a choice of
"None", "Regular", and "Strong":CONFIG_
CC_STACKPROTECT OR_NONE
CONFIG_CC_STACKPROTECT OR_REGULAR
CONFIG_CC_STACKPROTECT OR_STRONG "Regular" means the old CONFIG_
CC_STACKPROTECT OR=y option. "Strong" is a new mode introduced by this patch. With "Strong" the
kernel is built with -fstack-protector- strong (available in
gcc 4.9 and later). This option increases the coverage of the stack
protector without the heavy performance hit of -fstack-protector- all. For reference, the stack protector options available in gcc are:
-fstack-
protector- all:
Adds the stack-canary saving prefix and stack-canary checking
suffix to _all_ function entry and exit. Results in substantial
use of stack space for saving the canary for deep stack users
(e.g. historically xfs), and measurable (though shockingly still
low) performance hit due to all the saving/checking. Really not
suitable for sane systems, and was entirely removed as an option
from the kernel many years ago.-fstack-protector:
Adds the canary save/check to functions that define an 8
(--param=ssp-buffer- size=N, N=8 by default) or more byte local
char array. Traditionally, stack overflows happened with
string-based manipulations, so this was a way to find those
functions. Very few total functions actually get the canary; no
measurable performance or size overhead.-fstack-
protector- strong
Adds the canary for a wider set of functions, since it's not
just those with strings that have ultimately been vulnerable to
stack-busting. With this superset, more functions end up with a
canary, but it still remains small compared to all functions
with only a small change in performance. Based on the original
design document, a function gets the canary when it contains any
of:- local variable's address used as part of the right hand side
of an assignment or function argument
- local variable is an array (or union containing an array),
regardless of array type or length
- uses register local variableshttps:/
/docs.google. com/a/google. com/document/ d/1xXBH6rRZue4f 296vGt9YQcuLVQH eE516stHwt8M9xy U Find below a comparison of "size" and "objdump" output when built with
gcc-4.9 in three configurations:- defconfig
11430641 kernel text size
36110 function bodies- defconfig + CONFIG_
CC_STACKPROTECT OR_REGULAR
11468490 kernel text size (+0.33%)
1015 of 36110 functions are stack-protected (2.81%)- defconfig + CONFIG_
CC_STACKPROTECT OR_STRONG via this patch
11692790 kernel text size (+2.24%)
7401 of 36110 functions are stack-protected (20.5%)With -strong, ARM's compressed boot code now triggers stack
protection, so a static guard was added. Since this is only used
during decompression and was never used before, the exposure
here is very small. Once it switches to the full kernel, the
stack guard is back to normal.Chrome OS has been using -fstack-
protector- strong for its kernel
builds for the last 8 months with no problems.Signed-off-by: Kees Cook <email address hidden>
Cc: Arjan van de Ven <email address hidden>
Cc: Michal Marek <email address hidden>
Cc: Russell King <email address hidden>
Cc: Ralf Baechle <email address hidden>
Cc: Paul Mundt <email address hidden>
Cc: James Hogan <email address hidden>
Cc: Stephen Rothwell <email address hidden>
Cc: Shawn Guo <email address hidden>
Cc: Linus Torvalds <email address hidden>
Cc: Andrew Morton <email address hidden>
Cc: Peter Zijlstra <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Link: http://<email address hidden>
[ Improved the changelog and descriptions some more. ]
Signed-off-by: Ingo Molnar <email address hidden>
[ kamal: 3.13-stable: need these arch/arm/boot/compressed /misc.c __stack_chk
canary functions, even for just the old CONFIG_CC_STACKPROTECT OR ]
Signed-off-by: Kamal Mostafa <email address hidden> - ebc7575... by Kees Cook
-
stackprotector: Unify the HAVE_CC_
STACKPROTECTOR logic between architectures commit 19952a92037e752
f9d3bbbad552d59 6f9a56e146 upstream. Instead of duplicating the CC_STACKPROTECTOR Kconfig and
Makefile logic in each architecture, switch to using
HAVE_CC_STACKPROTECTOR and keep everything in one place. This
retains the x86-specific bug verification scripts.Signed-off-by: Kees Cook <email address hidden>
Cc: Arjan van de Ven <email address hidden>
Cc: Michal Marek <email address hidden>
Cc: Russell King <email address hidden>
Cc: Ralf Baechle <email address hidden>
Cc: Paul Mundt <email address hidden>
Cc: James Hogan <email address hidden>
Cc: Stephen Rothwell <email address hidden>
Cc: Shawn Guo <email address hidden>
Cc: Linus Torvalds <email address hidden>
Cc: Andrew Morton <email address hidden>
Cc: Peter Zijlstra <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Link: http://<email address hidden>
Signed-off-by: Ingo Molnar <email address hidden>
[ kamal: 3.13-stable prereq for
8779657 stackprotector: Introduce CONFIG_CC_STACKPROTECT OR_STRONG ]
Signed-off-by: Kamal Mostafa <email address hidden> - 5b25600... by Kamal Mostafa
-
Linux 3.13.11-ckt31
BugLink: http://
bugs.launchpad. net/bugs/ 1523661 Signed-off-by: Kamal Mostafa <email address hidden>
- 7792471... by Filipe Manana <email address hidden>
-
Btrfs: fix truncation of compressed and inlined extents
BugLink: http://
bugs.launchpad. net/bugs/ 1523661 commit 0305cd5f7fca85d
ae392b9ba85b116 896eb7c1c7 upstream. When truncating a file to a smaller size which consists of an inline
extent that is compressed, we did not discard (or made unusable) the
data between the new file size and the old file size, wasting metadata
space and allowing for the truncated data to be leaked and the data
corruption/loss mentioned below.
We were also not correctly decrementing the number of bytes used by the
inode, we were setting it to zero, giving a wrong report for callers of
the stat(2) syscall. The fsck tool also reported an error about a mismatch
between the nbytes of the file versus the real space used by the file.Now because we weren't discarding the truncated region of the file, it
was possible for a caller of the clone ioctl to actually read the data
that was truncated, allowing for a security breach without requiring root
access to the system, using only standard filesystem operations. The
scenario is the following:1) User A creates a file which consists of an inline and compressed
extent with a size of 2000 bytes - the file is not accessible to
any other users (no read, write or execution permission for anyone
else);2) The user truncates the file to a size of 1000 bytes;
3) User A makes the file world readable;
4) User B creates a file consisting of an inline extent of 2000 bytes;
5) User B issues a clone operation from user A's file into its own
file (using a length argument of 0, clone the whole range);6) User B now gets to see the 1000 bytes that user A truncated from
its file before it made its file world readbale. User B also lost
the bytes in the range [1000, 2000[ bytes from its own file, but
that might be ok if his/her intention was reading stale data from
user A that was never supposed to be public.Note that this contrasts with the case where we truncate a file from 2000
bytes to 1000 bytes and then truncate it back from 1000 to 2000 bytes. In
this case reading any byte from the range [1000, 2000[ will return a value
of 0x00, instead of the original data.This problem exists since the clone ioctl was added and happens both with
and without my recent data loss and file corruption fixes for the clone
ioctl (patch "Btrfs: fix file corruption and data loss after cloning
inline extents").So fix this by truncating the compressed inline extents as we do for the
non-compressed case, which involves decompressing, if the data isn't already
in the page cache, compressing the truncated version of the extent, writing
the compressed content into the inline extent and then truncate it.The following test case for fstests reproduces the problem. In order for
the test to pass both this fix and my previous fix for the clone ioctl
that forbids cloning a smaller inline extent into a larger one,
which is titled "Btrfs: fix file corruption and data loss after cloning
inline extents", are needed. Without that other fix the test fails in a
different way that does not leak the truncated data, instead part of
destination file gets replaced with zeroes (because the destination file
has a larger inline extent than the source).seq=`basename $0`
seqres=$RESULT_ DIR/$seq
echo "QA output created by $seq"
tmp=/tmp/$$
status=1 # failure is the default!
trap "_cleanup; exit \$status" 0 1 2 3 15_cleanup()
{
rm -f $tmp.*
}# get standard environment, filters and checks
. ./common/rc
. ./common/filter# real QA test starts here
_need_to_be_root
_supported_fs btrfs
_supported_os Linux
_require_scratch
_require_clonerrm -f $seqres.full
_scratch_mkfs >>$seqres.full 2>&1
_scratch_mount "-o compress"# Create our test files. File foo is going to be the source of a clone operation
# and consists of a single inline extent with an uncompressed size of 512 bytes,
# while file bar consists of a single inline extent with an uncompressed size of
# 256 bytes. For our test's purpose, it's important that file bar has an inline
# extent with a size smaller than foo's inline extent.
$XFS_IO_PROG -f -c "pwrite -S 0xa1 0 128" \
-c "pwrite -S 0x2a 128 384" \
$SCRATCH_ MNT/foo | _filter_xfs_io
$XFS_IO_PROG -f -c "pwrite -S 0xbb 0 256" $SCRATCH_MNT/bar | _filter_xfs_io# Now durably persist all metadata and data. We do this to make sure that we get
# on disk an inline extent with a size of 512 bytes for file foo.
sync# Now truncate our file foo to a smaller size. Because it consists of a
# compressed and inline extent, btrfs did not shrink the inline extent to the
# new size (if the extent was not compressed, btrfs would shrink it to 128
# bytes), it only updates the inode's i_size to 128 bytes.
$XFS_IO_PROG -c "truncate 128" $SCRATCH_MNT/foo# Now clone foo's inline extent into bar.
# This clone operation should fail with errno EOPNOTSUPP because the source
# file consists only of an inline extent and the file's size is smaller than
# the inline extent of the destination (128 bytes < 256 bytes). However the
# clone ioctl was not prepared to deal with a file that has a size smaller
# than the size of its inline extent (something that happens only for compressed
# inline extents), resulting in copying the full inline extent from the source
# file into the destination file.
#
# Note that btrfs' clone operation for inline extents consists of removing the
# inline extent from the destination inode and copy the inline extent from the
# source inode into the destination inode, meaning that if the destination
# inode's inline extent is larger (N bytes) than the source inode's inline
# extent (M bytes), some bytes (N - M bytes) will be lost from the destination
# file. Btrfs could copy the source inline extent's data into the destination's
# inline extent so that we would not lose any data, but that's currently not
# done due to the complexity that would be needed to deal with such cases
# (specially when one or both extents are compressed), returning EOPNOTSUPP, as
# it's normally not a very common case to clone very small files (only case
# where we get inline extents) and copying inline extents does not save any
# space (unlike for normal, non-inlined extents).
$CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/foo $SCRATCH_MNT/bar# Now because the above clone operation used to succeed, and due to foo's inline
# extent not being shinked by the truncate operation, our file bar got the whole
# inline extent copied from foo, making us lose the last 128 bytes from bar
# which got replaced by the bytes in range [128, 256[ from foo before foo was
# truncated - in other words, data loss from bar and being able to read old and
# stale data from foo that should not be possible to read anymore through normal
# filesystem operations. Contrast with the case where we truncate a file from a
# size N to a smaller size M, truncate it back to size N and then read the range
# [M, N[, we should always get the value 0x00 for all the bytes in that range.# We expected the clone operation to fail with errno EOPNOTSUPP and therefore
# not modify our file's bar data/metadata. So its content should be 256 bytes
# long with all bytes having the value 0xbb.
#
# Without the btrfs bug fix, the clone operation succeeded and resulted in
# leaking truncated data from foo, the bytes that belonged to its range
# [128, 256[, and losing data from bar in that same range. So reading the
# file gave us the following content:
#
# 0000000 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1 a1
# *
# 0000200 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a
# *
# 0000400
echo "File bar's content after the clone operation:"
od -t x1 $SCRATCH_MNT/bar# Also because the foo's inline extent was not shrunk by the truncate
# operation, btrfs' fsck, which is run by the fstests framework everytime a
# test completes, failed reporting the following error:
#
# root 5 inode 257 errors 400, nbytes wrongstatus=0
exitSigned-off-by: Filipe Manana <email address hidden>
[ kamal: backport 3.13-stable: root->ref_cows vs BTRFS_ROOT_REF_COWS; context ]
Signed-off-by: Kamal Mostafa <email address hidden> - 115c22f... by Chris Mason <email address hidden>
-
Btrfs: don't use ram_bytes for uncompressed inline items
BugLink: http://
bugs.launchpad. net/bugs/ 1523661 commit 514ac8ad8793a09
7c0c9d89202c642 479d6dfa34 upstream. If we truncate an uncompressed inline item, ram_bytes isn't updated to reflect
the new size. The fixe uses the size directly from the item header when
reading uncompressed inlines, and also fixes truncate to update the
size as it goes.Reported-by: Jens Axboe <email address hidden>
Signed-off-by: Chris Mason <email address hidden>
[ kamal: backport to 3.13-stable: applied to all _inline_len callers ]
Signed-off-by: Kamal Mostafa <email address hidden> - e110aeb... by Filipe Manana <email address hidden>
-
Btrfs: fix file corruption and data loss after cloning inline extents
BugLink: http://
bugs.launchpad. net/bugs/ 1523661 commit 8039d87d9e473ae
b740d4fdbd59b9d 2f89b2ced9 upstream. Currently the clone ioctl allows to clone an inline extent from one file
to another that already has other (non-inlined) extents. This is a problem
because btrfs is not designed to deal with files having inline and regular
extents, if a file has an inline extent then it must be the only extent
in the file and must start at file offset 0. Having a file with an inline
extent followed by regular extents results in EIO errors when doing reads
or writes against the first 4K of the file.Also, the clone ioctl allows one to lose data if the source file consists
of a single inline extent, with a size of N bytes, and the destination
file consists of a single inline extent with a size of M bytes, where we
have M > N. In this case the clone operation removes the inline extent
from the destination file and then copies the inline extent from the
source file into the destination file - we lose the M - N bytes from the
destination file, a read operation will get the value 0x00 for any bytes
in the the range [N, M] (the destination inode's i_size remained as M,
that's why we can read past N bytes).So fix this by not allowing such destructive operations to happen and
return errno EOPNOTSUPP to user space.Currently the fstest btrfs/035 tests the data loss case but it totally
ignores this - i.e. expects the operation to succeed and does not check
the we got data loss.The following test case for fstests exercises all these cases that result
in file corruption and data loss:seq=`basename $0`
seqres=$RESULT_ DIR/$seq
echo "QA output created by $seq"
tmp=/tmp/$$
status=1 # failure is the default!
trap "_cleanup; exit \$status" 0 1 2 3 15_cleanup()
{
rm -f $tmp.*
}# get standard environment, filters and checks
. ./common/rc
. ./common/filter# real QA test starts here
_need_to_be_root
_supported_fs btrfs
_supported_os Linux
_require_scratch
_require_cloner
_require_btrfs_fs_ feature "no_holes"
_require_btrfs_mkfs_ feature "no-holes" rm -f $seqres.full
test_
cloning_ inline_ extents( )
{
local mkfs_opts=$1
local mount_opts=$2_scratch_mkfs $mkfs_opts >>$seqres.full 2>&1
_scratch_ mount $mount_opts # File bar, the source for all the following clone operations, consists
# of a single inline extent (50 bytes).
$XFS_IO_PROG -f -c "pwrite -S 0xbb 0 50" $SCRATCH_MNT/bar \
| _filter_xfs_io# Test cloning into a file with an extent (non-inlined) where the
# destination offset overlaps that extent. It should not be possible to
# clone the inline extent from file bar into this file.
$XFS_IO_PROG -f -c "pwrite -S 0xaa 0K 16K" $SCRATCH_MNT/foo \
| _filter_xfs_io
$CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo# Doing IO against any range in the first 4K of the file should work.
# Due to a past clone ioctl bug which allowed cloning the inline extent,
# these operations resulted in EIO errors.
echo "File foo data after clone operation:"
# All bytes should have the value 0xaa (clone operation failed and did
# not modify our file).
od -t x1 $SCRATCH_MNT/foo
$XFS_IO_PROG -c "pwrite -S 0xcc 0 100" $SCRATCH_MNT/foo | _filter_xfs_io# Test cloning the inline extent against a file which has a hole in its
# first 4K followed by a non-inlined extent. It should not be possible
# as well to clone the inline extent from file bar into this file.
$XFS_IO_PROG -f -c "pwrite -S 0xdd 4K 12K" $SCRATCH_MNT/foo2 \
| _filter_xfs_io
$CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo2# Doing IO against any range in the first 4K of the file should work.
# Due to a past clone ioctl bug which allowed cloning the inline extent,
# these operations resulted in EIO errors.
echo "File foo2 data after clone operation:"
# All bytes should have the value 0x00 (clone operation failed and did
# not modify our file).
od -t x1 $SCRATCH_MNT/foo2
$XFS_IO_PROG -c "pwrite -S 0xee 0 90" $SCRATCH_MNT/foo2 | _filter_xfs_io# Test cloning the inline extent against a file which has a size of zero
# but has a prealloc extent. It should not be possible as well to clone
# the inline extent from file bar into this file.
$XFS_IO_PROG -f -c "falloc -k 0 1M" $SCRATCH_MNT/foo3 | _filter_xfs_io
$CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo3# Doing IO against any range in the first 4K of the file should work.
# Due to a past clone ioctl bug which allowed cloning the inline extent,
# these operations resulted in EIO errors.
echo "First 50 bytes of foo3 after clone operation:"
# Should not be able to read any bytes, file has 0 bytes i_size (the
# clone operation failed and did not modify our file).
od -t x1 $SCRATCH_MNT/foo3
$XFS_IO_PROG -c "pwrite -S 0xff 0 90" $SCRATCH_MNT/foo3 | _filter_xfs_io# Test cloning the inline extent against a file which consists of a
# single inline extent that has a size not greater than the size of
# bar's inline extent (40 < 50).
# It should be possible to do the extent cloning from bar to this file.
$XFS_IO_PROG -f -c "pwrite -S 0x01 0 40" $SCRATCH_MNT/foo4 \
| _filter_xfs_io
$CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo4# Doing IO against any range in the first 4K of the file should work.
echo "File foo4 data after clone operation:"
# Must match file bar's content.
od -t x1 $SCRATCH_MNT/foo4
$XFS_IO_PROG -c "pwrite -S 0x02 0 90" $SCRATCH_MNT/foo4 | _filter_xfs_io# Test cloning the inline extent against a file which consists of a
# single inline extent that has a size greater than the size of bar's
# inline extent (60 > 50).
# It should not be possible to clone the inline extent from file bar
# into this file.
$XFS_IO_PROG -f -c "pwrite -S 0x03 0 60" $SCRATCH_MNT/foo5 \
| _filter_xfs_io
$CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo5# Reading the file should not fail.
echo "File foo5 data after clone operation:"
# Must have a size of 60 bytes, with all bytes having a value of 0x03
# (the clone operation failed and did not modify our file).
od -t x1 $SCRATCH_MNT/foo5# Test cloning the inline extent against a file which has no extents but
# has a size greater than bar's inline extent (16K > 50).
# It should not be possible to clone the inline extent from file bar
# into this file.
$XFS_IO_PROG -f -c "truncate 16K" $SCRATCH_MNT/foo6 | _filter_xfs_io
$CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo6# Reading the file should not fail.
echo "File foo6 data after clone operation:"
# Must have a size of 16K, with all bytes having a value of 0x00 (the
# clone operation failed and did not modify our file).
od -t x1 $SCRATCH_MNT/foo6# Test cloning the inline extent against a file which has no extents but
# has a size not greater than bar's inline extent (30 < 50).
# It should be possible to clone the inline extent from file bar into
# this file.
$XFS_IO_PROG -f -c "truncate 30" $SCRATCH_MNT/foo7 | _filter_xfs_io
$CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo7# Reading the file should not fail.
echo "File foo7 data after clone operation:"
# Must have a size of 50 bytes, with all bytes having a value of 0xbb.
od -t x1 $SCRATCH_MNT/foo7# Test cloning the inline extent against a file which has a size not
# greater than the size of bar's inline extent (20 < 50) but has
# a prealloc extent that goes beyond the file's size. It should not be
# possible to clone the inline extent from bar into this file.
$XFS_IO_PROG -f -c "falloc -k 0 1M" \
-c "pwrite -S 0x88 0 20" \
$SCRATCH_ MNT/foo8 | _filter_xfs_io
$CLONER_PROG -s 0 -d 0 -l 0 $SCRATCH_MNT/bar $SCRATCH_MNT/foo8echo "File foo8 data after clone operation:"
# Must have a size of 20 bytes, with all bytes having a value of 0x88
# (the clone operation did not modify our file).
od -t x1 $SCRATCH_MNT/foo8_
scratch_ unmount
}echo -e "\nTesting without compression and without the no-holes feature...\n"
test_cloning_ inline_ extents echo -e "\nTesting with compression and without the no-holes feature...\n"
test_cloning_ inline_ extents "" "-o compress" echo -e "\nTesting without compression and with the no-holes feature...\n"
test_cloning_ inline_ extents "-O no-holes" "" echo -e "\nTesting with compression and with the no-holes feature...\n"
test_cloning_ inline_ extents "-O no-holes" "-o compress" status=0
exitSigned-off-by: Filipe Manana <email address hidden>
[ kamal: backport to 3.13-stable: context ]
Signed-off-by: Kamal Mostafa <email address hidden> - 8c00b96... by tititou
-
TPM: Avoid reference to potentially freed memory
BugLink: http://
bugs.launchpad. net/bugs/ 1523661 commit eb8ed1eb9a158c4
60d10205eaff71f d4ac67c160 upstream. Reference to the 'np' node is dropped before dereferencing the 'sizep' and
'basep' pointers, which could by then point to junk if the node has been
freed.Refactor code to call 'of_node_put' later.
Fixes: c5df39262dd5 ("drivers/char/tpm: Add securityfs support for event log")
Signed-off-by: Christophe JAILLET <email address hidden>
Reviewed-by: Jarkko Sakkinen <email address hidden>
Signed-off-by: Jarkko Sakkinen <email address hidden>
Acked-by: Peter Huewe <email address hidden>
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden> - 718bafd... by Florian Westphal <email address hidden>
-
netfilter: nfnetlink: don't probe module if it exists
BugLink: http://
bugs.launchpad. net/bugs/ 1523661 commit dbc3617f4c1f9fc
be63612048cb958 3fea1e11ab upstream. nfnetlink_bind request_module()s all the time as nfnetlink_
get_subsys( )
shifts the argument by 8 to obtain the subsys id.So using type instead of type << 8 always returns NULL.
Fixes: 03292745b02d11 ("netlink: add nlk->netlink_bind hook for module auto-loading")
Signed-off-by: Florian Westphal <email address hidden>
Signed-off-by: Pablo Neira Ayuso <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>