From 7e5e21848dee743095cd8bf64769760fc9e68db5 Mon Sep 17 00:00:00 2001 From: Josh Boyer Date: Fri, 27 Feb 2015 09:52:17 -0500 Subject: [PATCH] Linux v3.18.8 --- ...urnal-checksum-on-remount-don-t-fail.patch | 45 ------ ...e-dst_entries-which-would-cause-a-re.patch | 99 ------------- kernel.spec | 23 +-- ...b-corruption-from-use-after-free-on-.patch | 131 ------------------ sources | 2 +- 5 files changed, 5 insertions(+), 295 deletions(-) delete mode 100644 ext4-ignore-journal-checksum-on-remount-don-t-fail.patch delete mode 100644 ipv4-try-to-cache-dst_entries-which-would-cause-a-re.patch delete mode 100644 net-sctp-fix-slab-corruption-from-use-after-free-on-.patch diff --git a/ext4-ignore-journal-checksum-on-remount-don-t-fail.patch b/ext4-ignore-journal-checksum-on-remount-don-t-fail.patch deleted file mode 100644 index 6a52e78a0..000000000 --- a/ext4-ignore-journal-checksum-on-remount-don-t-fail.patch +++ /dev/null @@ -1,45 +0,0 @@ -From: Eric Sandeen -Date: Thu, 12 Feb 2015 23:07:37 -0500 -Subject: [PATCH] ext4: ignore journal checksum on remount; don't fail -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8 -Content-Transfer-Encoding: 8bit - -As of v3.18, ext4 started rejecting a remount which changes the -journal_checksum option. - -Prior to that, it was simply ignored; the problem here is that -if someone has this in their fstab for the root fs, now the box -fails to boot properly, because remount of root with the new options -will fail, and the box proceeds with a readonly root. - -I think it is a little nicer behavior to accept the option, but -warn that it's being ignored, rather than failing the mount, -but that might be a subjective matter... - -Reported-by: Cónräd -Signed-off-by: Eric Sandeen -Signed-off-by: Theodore Ts'o ---- - fs/ext4/super.c | 5 ++--- - 1 file changed, 2 insertions(+), 3 deletions(-) - -diff --git a/fs/ext4/super.c b/fs/ext4/super.c -index 2c9e6864abd9..fc7391e14c2a 100644 ---- a/fs/ext4/super.c -+++ b/fs/ext4/super.c -@@ -4849,9 +4849,8 @@ static int ext4_remount(struct super_block *sb, int *flags, char *data) - if ((old_opts.s_mount_opt & EXT4_MOUNT_JOURNAL_CHECKSUM) ^ - test_opt(sb, JOURNAL_CHECKSUM)) { - ext4_msg(sb, KERN_ERR, "changing journal_checksum " -- "during remount not supported"); -- err = -EINVAL; -- goto restore_opts; -+ "during remount not supported; ignoring"); -+ sbi->s_mount_opt ^= EXT4_MOUNT_JOURNAL_CHECKSUM; - } - - if (test_opt(sb, DATA_FLAGS) == EXT4_MOUNT_JOURNAL_DATA) { --- -2.1.0 - diff --git a/ipv4-try-to-cache-dst_entries-which-would-cause-a-re.patch b/ipv4-try-to-cache-dst_entries-which-would-cause-a-re.patch deleted file mode 100644 index fbafb5342..000000000 --- a/ipv4-try-to-cache-dst_entries-which-would-cause-a-re.patch +++ /dev/null @@ -1,99 +0,0 @@ -From: Hannes Frederic Sowa -Date: Fri, 23 Jan 2015 12:01:26 +0100 -Subject: [PATCH] ipv4: try to cache dst_entries which would cause a redirect - -Not caching dst_entries which cause redirects could be exploited by hosts -on the same subnet, causing a severe DoS attack. This effect aggravated -since commit f88649721268999 ("ipv4: fix dst race in sk_dst_get()"). - -Lookups causing redirects will be allocated with DST_NOCACHE set which -will force dst_release to free them via RCU. Unfortunately waiting for -RCU grace period just takes too long, we can end up with >1M dst_entries -waiting to be released and the system will run OOM. rcuos threads cannot -catch up under high softirq load. - -Attaching the flag to emit a redirect later on to the specific skb allows -us to cache those dst_entries thus reducing the pressure on allocation -and deallocation. - -This issue was discovered by Marcelo Leitner. - -Cc: Julian Anastasov -Signed-off-by: Marcelo Leitner -Signed-off-by: Florian Westphal -Signed-off-by: Hannes Frederic Sowa -Signed-off-by: Julian Anastasov -Signed-off-by: David S. Miller ---- - include/net/ip.h | 11 ++++++----- - net/ipv4/ip_forward.c | 3 ++- - net/ipv4/route.c | 9 +++++---- - 3 files changed, 13 insertions(+), 10 deletions(-) - -diff --git a/include/net/ip.h b/include/net/ip.h -index 0bb620702929..f7cbd703d15d 100644 ---- a/include/net/ip.h -+++ b/include/net/ip.h -@@ -39,11 +39,12 @@ struct inet_skb_parm { - struct ip_options opt; /* Compiled IP options */ - unsigned char flags; - --#define IPSKB_FORWARDED 1 --#define IPSKB_XFRM_TUNNEL_SIZE 2 --#define IPSKB_XFRM_TRANSFORMED 4 --#define IPSKB_FRAG_COMPLETE 8 --#define IPSKB_REROUTED 16 -+#define IPSKB_FORWARDED BIT(0) -+#define IPSKB_XFRM_TUNNEL_SIZE BIT(1) -+#define IPSKB_XFRM_TRANSFORMED BIT(2) -+#define IPSKB_FRAG_COMPLETE BIT(3) -+#define IPSKB_REROUTED BIT(4) -+#define IPSKB_DOREDIRECT BIT(5) - - u16 frag_max_size; - }; -diff --git a/net/ipv4/ip_forward.c b/net/ipv4/ip_forward.c -index 3a83ce5efa80..787b3c294ce6 100644 ---- a/net/ipv4/ip_forward.c -+++ b/net/ipv4/ip_forward.c -@@ -129,7 +129,8 @@ int ip_forward(struct sk_buff *skb) - * We now generate an ICMP HOST REDIRECT giving the route - * we calculated. - */ -- if (rt->rt_flags&RTCF_DOREDIRECT && !opt->srr && !skb_sec_path(skb)) -+ if (IPCB(skb)->flags & IPSKB_DOREDIRECT && !opt->srr && -+ !skb_sec_path(skb)) - ip_rt_send_redirect(skb); - - skb->priority = rt_tos2priority(iph->tos); -diff --git a/net/ipv4/route.c b/net/ipv4/route.c -index 6a2155b02602..d58dd0ec3e53 100644 ---- a/net/ipv4/route.c -+++ b/net/ipv4/route.c -@@ -1554,11 +1554,10 @@ static int __mkroute_input(struct sk_buff *skb, - - do_cache = res->fi && !itag; - if (out_dev == in_dev && err && IN_DEV_TX_REDIRECTS(out_dev) && -+ skb->protocol == htons(ETH_P_IP) && - (IN_DEV_SHARED_MEDIA(out_dev) || -- inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res)))) { -- flags |= RTCF_DOREDIRECT; -- do_cache = false; -- } -+ inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res)))) -+ IPCB(skb)->flags |= IPSKB_DOREDIRECT; - - if (skb->protocol != htons(ETH_P_IP)) { - /* Not IP (i.e. ARP). Do not create route, if it is -@@ -2303,6 +2302,8 @@ static int rt_fill_info(struct net *net, __be32 dst, __be32 src, - r->rtm_flags = (rt->rt_flags & ~0xFFFF) | RTM_F_CLONED; - if (rt->rt_flags & RTCF_NOTIFY) - r->rtm_flags |= RTM_F_NOTIFY; -+ if (IPCB(skb)->flags & IPSKB_DOREDIRECT) -+ r->rtm_flags |= RTCF_DOREDIRECT; - - if (nla_put_be32(skb, RTA_DST, dst)) - goto nla_put_failure; --- -2.1.0 - diff --git a/kernel.spec b/kernel.spec index 209dab91d..9f114b65c 100644 --- a/kernel.spec +++ b/kernel.spec @@ -74,7 +74,7 @@ Summary: The Linux kernel %if 0%{?released_kernel} # Do we have a -stable update to apply? -%define stable_update 7 +%define stable_update 8 # Is it a -stable RC? %define stable_rc 0 # Set rpm version accordingly @@ -749,9 +749,6 @@ Patch30000: kernel-arm64.patch # Fix for big-endian arches, already upstream Patch30001: mpssd-x86-only.patch -# rhbz 1183744 1188347 -Patch30002: ipv4-try-to-cache-dst_entries-which-would-cause-a-re.patch - #rhbz 1188074 Patch30003: 0001-ntp-Fixup-adjtimex-freq-validation-on-32bit-systems.patch @@ -770,15 +767,9 @@ Patch26138: ext4-Allocate-entire-range-in-zero-range.patch #rhbz 1188439 Patch26139: HID-i2c-hid-Limit-reads-to-wMaxInputLength-bytes-for.patch -#rhbz 1190933 -Patch26140: ext4-ignore-journal-checksum-on-remount-don-t-fail.patch - #rhbz 1190947 Patch26141: Bluetooth-ath3k-Add-support-Atheros-AR5B195-combo-Mi.patch -#CVE-2015-1421 rhbz 1196581 1196595 -Patch26142: net-sctp-fix-slab-corruption-from-use-after-free-on-.patch - # END OF PATCH DEFINITIONS %endif @@ -1491,9 +1482,6 @@ ApplyPatch acpi-video-Add-disable_native_backlight-quirk-for-Sa.patch # Fix for big-endian arches, already upstream ApplyPatch mpssd-x86-only.patch -# rhbz 1183744 1188347 -ApplyPatch ipv4-try-to-cache-dst_entries-which-would-cause-a-re.patch - #rhbz 1188074 ApplyPatch 0001-ntp-Fixup-adjtimex-freq-validation-on-32bit-systems.patch @@ -1512,15 +1500,9 @@ ApplyPatch ext4-Allocate-entire-range-in-zero-range.patch #rhbz 1188439 ApplyPatch HID-i2c-hid-Limit-reads-to-wMaxInputLength-bytes-for.patch -#rhbz 1190933 -ApplyPatch ext4-ignore-journal-checksum-on-remount-don-t-fail.patch - #rhbz 1190947 ApplyPatch Bluetooth-ath3k-Add-support-Atheros-AR5B195-combo-Mi.patch -#CVE-2015-1421 rhbz 1196581 1196595 -ApplyPatch net-sctp-fix-slab-corruption-from-use-after-free-on-.patch - %if 0%{?aarch64patches} ApplyPatch kernel-arm64.patch %ifnarch aarch64 # this is stupid, but i want to notice before secondary koji does. @@ -2339,6 +2321,9 @@ fi # ||----w | # || || %changelog +* Fri Feb 27 2015 Josh Boyer - CVE-2015-1421 sctp: slab corruption from use after free on INIT collisions (rhbz 1196581 1196595) diff --git a/net-sctp-fix-slab-corruption-from-use-after-free-on-.patch b/net-sctp-fix-slab-corruption-from-use-after-free-on-.patch deleted file mode 100644 index 65796dbb2..000000000 --- a/net-sctp-fix-slab-corruption-from-use-after-free-on-.patch +++ /dev/null @@ -1,131 +0,0 @@ -From: Daniel Borkmann -Date: Thu, 22 Jan 2015 18:26:54 +0100 -Subject: [PATCH] net: sctp: fix slab corruption from use after free on INIT - collisions - -When hitting an INIT collision case during the 4WHS with AUTH enabled, as -already described in detail in commit 1be9a950c646 ("net: sctp: inherit -auth_capable on INIT collisions"), it can happen that we occasionally -still remotely trigger the following panic on server side which seems to -have been uncovered after the fix from commit 1be9a950c646 ... - -[ 533.876389] BUG: unable to handle kernel paging request at 00000000ffffffff -[ 533.913657] IP: [] __kmalloc+0x95/0x230 -[ 533.940559] PGD 5030f2067 PUD 0 -[ 533.957104] Oops: 0000 [#1] SMP -[ 533.974283] Modules linked in: sctp mlx4_en [...] -[ 534.939704] Call Trace: -[ 534.951833] [] ? crypto_init_shash_ops+0x60/0xf0 -[ 534.984213] [] crypto_init_shash_ops+0x60/0xf0 -[ 535.015025] [] __crypto_alloc_tfm+0x6d/0x170 -[ 535.045661] [] crypto_alloc_base+0x4c/0xb0 -[ 535.074593] [] ? _raw_spin_lock_bh+0x12/0x50 -[ 535.105239] [] sctp_inet_listen+0x161/0x1e0 [sctp] -[ 535.138606] [] SyS_listen+0x9d/0xb0 -[ 535.166848] [] system_call_fastpath+0x16/0x1b - -... or depending on the the application, for example this one: - -[ 1370.026490] BUG: unable to handle kernel paging request at 00000000ffffffff -[ 1370.026506] IP: [] kmem_cache_alloc+0x75/0x1d0 -[ 1370.054568] PGD 633c94067 PUD 0 -[ 1370.070446] Oops: 0000 [#1] SMP -[ 1370.085010] Modules linked in: sctp kvm_amd kvm [...] -[ 1370.963431] Call Trace: -[ 1370.974632] [] ? SyS_epoll_ctl+0x53f/0x960 -[ 1371.000863] [] SyS_epoll_ctl+0x53f/0x960 -[ 1371.027154] [] ? anon_inode_getfile+0xd3/0x170 -[ 1371.054679] [] ? __alloc_fd+0xa7/0x130 -[ 1371.080183] [] system_call_fastpath+0x16/0x1b - -With slab debugging enabled, we can see that the poison has been overwritten: - -[ 669.826368] BUG kmalloc-128 (Tainted: G W ): Poison overwritten -[ 669.826385] INFO: 0xffff880228b32e50-0xffff880228b32e50. First byte 0x6a instead of 0x6b -[ 669.826414] INFO: Allocated in sctp_auth_create_key+0x23/0x50 [sctp] age=3 cpu=0 pid=18494 -[ 669.826424] __slab_alloc+0x4bf/0x566 -[ 669.826433] __kmalloc+0x280/0x310 -[ 669.826453] sctp_auth_create_key+0x23/0x50 [sctp] -[ 669.826471] sctp_auth_asoc_create_secret+0xcb/0x1e0 [sctp] -[ 669.826488] sctp_auth_asoc_init_active_key+0x68/0xa0 [sctp] -[ 669.826505] sctp_do_sm+0x29d/0x17c0 [sctp] [...] -[ 669.826629] INFO: Freed in kzfree+0x31/0x40 age=1 cpu=0 pid=18494 -[ 669.826635] __slab_free+0x39/0x2a8 -[ 669.826643] kfree+0x1d6/0x230 -[ 669.826650] kzfree+0x31/0x40 -[ 669.826666] sctp_auth_key_put+0x19/0x20 [sctp] -[ 669.826681] sctp_assoc_update+0x1ee/0x2d0 [sctp] -[ 669.826695] sctp_do_sm+0x674/0x17c0 [sctp] - -Since this only triggers in some collision-cases with AUTH, the problem at -heart is that sctp_auth_key_put() on asoc->asoc_shared_key is called twice -when having refcnt 1, once directly in sctp_assoc_update() and yet again -from within sctp_auth_asoc_init_active_key() via sctp_assoc_update() on -the already kzfree'd memory, which is also consistent with the observation -of the poison decrease from 0x6b to 0x6a (note: the overwrite is detected -at a later point in time when poison is checked on new allocation). - -Reference counting of auth keys revisited: - -Shared keys for AUTH chunks are being stored in endpoints and associations -in endpoint_shared_keys list. On endpoint creation, a null key is being -added; on association creation, all endpoint shared keys are being cached -and thus cloned over to the association. struct sctp_shared_key only holds -a pointer to the actual key bytes, that is, struct sctp_auth_bytes which -keeps track of users internally through refcounting. Naturally, on assoc -or enpoint destruction, sctp_shared_key are being destroyed directly and -the reference on sctp_auth_bytes dropped. - -User space can add keys to either list via setsockopt(2) through struct -sctp_authkey and by passing that to sctp_auth_set_key() which replaces or -adds a new auth key. There, sctp_auth_create_key() creates a new sctp_auth_bytes -with refcount 1 and in case of replacement drops the reference on the old -sctp_auth_bytes. A key can be set active from user space through setsockopt() -on the id via sctp_auth_set_active_key(), which iterates through either -endpoint_shared_keys and in case of an assoc, invokes (one of various places) -sctp_auth_asoc_init_active_key(). - -sctp_auth_asoc_init_active_key() computes the actual secret from local's -and peer's random, hmac and shared key parameters and returns a new key -directly as sctp_auth_bytes, that is asoc->asoc_shared_key, plus drops -the reference if there was a previous one. The secret, which where we -eventually double drop the ref comes from sctp_auth_asoc_set_secret() with -intitial refcount of 1, which also stays unchanged eventually in -sctp_assoc_update(). This key is later being used for crypto layer to -set the key for the hash in crypto_hash_setkey() from sctp_auth_calculate_hmac(). - -To close the loop: asoc->asoc_shared_key is freshly allocated secret -material and independant of the sctp_shared_key management keeping track -of only shared keys in endpoints and assocs. Hence, also commit 4184b2a79a76 -("net: sctp: fix memory leak in auth key management") is independant of -this bug here since it concerns a different layer (though same structures -being used eventually). asoc->asoc_shared_key is reference dropped correctly -on assoc destruction in sctp_association_free() and when active keys are -being replaced in sctp_auth_asoc_init_active_key(), it always has a refcount -of 1. Hence, it's freed prematurely in sctp_assoc_update(). Simple fix is -to remove that sctp_auth_key_put() from there which fixes these panics. - -Fixes: 730fc3d05cd4 ("[SCTP]: Implete SCTP-AUTH parameter processing") -Signed-off-by: Daniel Borkmann -Acked-by: Vlad Yasevich -Acked-by: Neil Horman -Signed-off-by: David S. Miller ---- - net/sctp/associola.c | 1 - - 1 file changed, 1 deletion(-) - -diff --git a/net/sctp/associola.c b/net/sctp/associola.c -index f791edd64d6c..26d06dbcc1c8 100644 ---- a/net/sctp/associola.c -+++ b/net/sctp/associola.c -@@ -1182,7 +1182,6 @@ void sctp_assoc_update(struct sctp_association *asoc, - asoc->peer.peer_hmacs = new->peer.peer_hmacs; - new->peer.peer_hmacs = NULL; - -- sctp_auth_key_put(asoc->asoc_shared_key); - sctp_auth_asoc_init_active_key(asoc, GFP_ATOMIC); - } - --- -2.1.0 - diff --git a/sources b/sources index 31a89f1fd..ac091960e 100644 --- a/sources +++ b/sources @@ -1,3 +1,3 @@ 9e854df51ca3fef8bfe566dbd7b89241 linux-3.18.tar.xz 813ccb96f0b379d656e57442c2587ca3 perf-man-3.18.tar.gz -9db3178b87ddf7c05e6191bf57645610 patch-3.18.7.xz +b7bd36ce9f4bff165ee776e2b9263257 patch-3.18.8.xz