This repository has been archived by the owner on May 1, 2020. It is now read-only.
Test #10
Merged
Test #10
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Explicitly clear the subsystem loading address in case of any memory failure. It will help to avoid any platform dependency. Change-Id: I3be8f6318d68f02c02e637fc34f4a868e9fafa45 Signed-off-by: Gaurav Kohli <gkohli@codeaurora.org> Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
Add feed state check whether any filter is configured on dvbdemux feed before feed stop is called. If any filter is started the feed status should be set to DMX_STATE_GO. CRs-Fixed: 1090466 Change-Id: I8dfa9e5b656a1aa71f4bc1abdc05ff146869088d Signed-off-by: Udaya Bhaskara Reddy Mallavarapu <udaym@codeaurora.org>
Serialize core_info_read with lock so that multiple concurrent threads do not cause the write to overflow. Also have the bound check to avoid overflow in write_str function. CRs-Fixed: 2013361 Change-Id: Ia18a4b94cafd69af1d367861f2499fc202f18e9f Signed-off-by: Abdulla Anam <abdullahanam@codeaurora.org> Signed-off-by: Sanjay Singh <sisanj@codeaurora.org>
Eagle driver is not in use any more. Remove the code and associated calls to it. CRs-Fixed: 1103106 Change-Id: Ice5333861beda9538f0783b70b3267523d16fd2b Signed-off-by: Alexy Joseph <alexyj@codeaurora.org>
Remove unused debug function that trigger MSI Change-Id: Ib747e579c732ece892f8695f2fdfbf107012c9c8 CRs-Fixed: 1116611 Signed-off-by: Prasad Malisetty <prasadm@codeaurora.org>
To notify client that tz app is not found, change _qseecom_send_cmd return errno to -ENOENT if app is not found. Besides, save app name in kernel client handle if that app exists or is loaded for the first time. Change-Id: Ib8da680601bcc823401403299b84889593db715b Signed-off-by: Zhen Kong <zkong@codeaurora.org>
Add boundary check for cci master in i2c_read. This value is passed from userpsace. If user sends an invalid number for master there is a possibility of accessing unintended buffer. This change addresses the issue. CRs-Fixed: 1086764 Signed-off-by: Rajesh Bondugula <rajeshb@codeaurora.org> Signed-off-by: VijayaKumar T M <vtmuni@codeaurora.org> Change-Id: Ice3bde902aea96382ceb4dfddfd28a5ea89c183d
Free the memory pointed by msg pointer if copy_to_user fails. Change-Id: I628e089d844a3e1818a1a550e77ac10f33640ac9 Acked-by: Mohammed Javid <mjavid@qti.qualcomm.com> Signed-off-by: Utkarsh Saxena <usaxena@codeaurora.org>
The cache maintenance routines in ashmem were causing several security issues. Since they are not being used anymore by any drivers, its well to remove them entirely. CRs-Fixed: 1107034, 2001129, 2007786 Change-Id: I955e33d90b888d58db5cf6bb490905283374425b Signed-off-by: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
Make opened device count atomic variable to avoid probable race condition. Race condition leads to memory leak and list corruption. Change-Id: I4da98f27d36f616bc8fa7b1a848c20cc7eea04e5 Signed-off-by: Divya Ojha <dojha@codeaurora.org>
In multi-threaded environment diglen variable could be modified by multiple threads at the same time. Buffer overflow might happen in current thread if another thread changes the diglen variable. So add mutex locks to avoid this issue. Change-Id: I62c63c55c028dedb1dd0eec862851bd8e818a5d3 Signed-off-by: AnilKumar Chimata <anilc@codeaurora.org>
As debugfs interface is intended to test the respective ssr, remove from the driver to make sure it won't be available by default. CRs-Fixed: 2025661 Change-Id: I6af9a8333c8028611f889cc2f9b0beb37ef12c9b Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
Fix race condition in the release of the mdp debugfs functions panel_debug_base_release and mdss_debug_base_release by adding the lock for unpreempted freeing of the buffer so that multiple concurrent processes cannot affect the release which can possibly lead to use-after-free operation on the buffer. Change-Id: I9586081b65ae2eb0e7f6e30c606ee748ae9ef7e8 Signed-off-by: Harsh Sahu <hsahu@codeaurora.org>
The wcnss platform driver update the wlan calibration data by the user space wlan daemon. The wlan user space daemon store the updated wlan calibration data reported by wlan firmware in user space and write it back to the wcnss platform calibration data buffer for the calibration data download and update. During the wlan calibration data store and retrieve operation there are some potential race condition which leads to memory leak and buffer overflow during the context switch. Fix the above issue by adding protection code and avoid usage of global pointer during the device file read and write operation. CRs-Fixed: 2015858 Change-Id: Ib5b57eb86dcb4e6ed799b5222d06396eaabfaad3 Signed-off-by: Sarada Prasanna Garnayak <sgarna@codeaurora.org>
A audio_process_event_req is not always to success. Therefore, check the return value for audio_process_event_req, and initializ usr_evt before using it. CRs-Fixed: 2029798 Change-Id: I4adf682575f5f9233a1a1a533f9c6361af8a5bcf Signed-off-by: kunleiz <kunleiz@codeaurora.org>
Backport of this upstream commit into stable kernels : 89c22d8 ("net: Fix skb csum races when peeking") exposed a bug in udp stack vs MSG_PEEK support, when user provides a buffer smaller than skb payload. In this case, skb_copy_and_csum_datagram_iovec(skb, sizeof(struct udphdr), msg->msg_iov); returns -EFAULT. This bug does not happen in upstream kernels since Al Viro did a great job to replace this into : skb_copy_and_csum_datagram_msg(skb, sizeof(struct udphdr), msg); This variant is safe vs short buffers. For the time being, instead reverting Herbert Xu patch and add back skb->ip_summed invalid changes, simply store the result of udp_lib_checksum_complete() so that we avoid computing the checksum a second time, and avoid the problematic skb_copy_and_csum_datagram_iovec() call. This patch can be applied on recent kernels as it avoids a double checksumming, then backported to stable kernels as a bug fix. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> [d-cagle@codeaurora.org: Resolve trivial merge conflicts] Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Git-commit: 197c949 Change-Id: I70f19a362f627bd2d9d8e10e31bbcdb4b0600792 Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
This separates the kref for ion handles into two components. Userspace requests through the ioctl will hold at most one reference to the internally used kref. All additional requests will increment a separate counter, and the original reference is only put once that counter hits 0. This protects the kernel from a poorly behaving userspace. Bug: 34276203 Change-Id: Ibc36bc4405788ed0fea7337b541cad3be2b934c0 Signed-off-by: Daniel Rosenberg <drosen@google.com> Git-repo: https://android.googlesource.com/kernel/msm/ Git-commit: 20abfcc [d-cagle@codeaurora.org: Resolve style issues] Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
When file permissions are modified via chmod(2) and the user is not in the owning group or capable of CAP_FSETID, the setgid bit is cleared in inode_change_ok(). Setting a POSIX ACL via setxattr(2) sets the file permissions as well as the new ACL, but doesn't clear the setgid bit in a similar way; this allows to bypass the check in chmod(2). Fix that. References: CVE-2016-7097 Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/ linux.git Git-commit: 0739310 Change-Id: Idf7cd8d0fb030fedeabd46254e4c4a9c08bce8b5 [d-cagle@codeaurora.org: Resolve merge conflicts and style] Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org> [stummala@codeaurora.org: Resolve merge conflicts on existing files and skip files fs/ceph/acl.c, fs/hfsplus/posix_acl.c and fs/jfs/acl.c from original change as those files are not present/fix is not applicable on 3.10 kernel] Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Set address to NULL on error to ensure a stale address is not used. CRs-Fixed: 2038685 Signed-off-by: Siena Richard <sienar@codeaurora.org> Change-Id: I17e7b7b404625d21721b2466e70fa8be2370b517
Use proper synchronization to ensure driver file is opened only once. CRs-Fixed: 2023513 Change-Id: I71e55e2d487fe561d3f596590b3e8102c5e921b5 Signed-off-by: Trishansh Bhardwaj <tbhardwa@codeaurora.org>
When a new xfrm state is created during an XFRM_MSG_NEWSA call we validate the user supplied replay_esn to ensure that the size is valid and to ensure that the replay_window size is within the allocated buffer. However later it is possible to update this replay_esn via a XFRM_MSG_NEWAE call. There we again validate the size of the supplied buffer matches the existing state and if so inject the contents. We do not at this point check that the replay_window is within the allocated memory. This leads to out-of-bounds reads and writes triggered by netlink packets. This leads to memory corruption and the potential for privilege escalation. We already attempt to validate the incoming replay information in xfrm_new_ae() via xfrm_replay_verify_len(). This confirms that the user is not trying to change the size of the replay state buffer which includes the replay_esn. It however does not check the replay_window remains within that buffer. Add validation of the contained replay_window. CVE-2017-7184 Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Change-Id: Ifc8055e9d3ee94c3e017f1f9b0be06cd171844a6 Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: 677e806 Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
Kees Cook has pointed out that xfrm_replay_state_esn_len() is subject to wrapping issues. To ensure we are correctly ensuring that the two ESN structures are the same size compare both the overall size as reported by xfrm_replay_state_esn_len() and the internal length are the same. CVE-2017-7184 Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Change-Id: I035fb0bbb9449fc999d83302c8343b0700316229 Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: f843ee6 Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
The size of uvc_control_mapping is user controlled leading to a potential heap overflow in the uvc driver. This adds a check to verify the user provided size fits within the bounds of the defined buffer size. Bug: 33300353 Change-Id: If29c1b396633b6137966a12e38f6fd1841b045bd Signed-off-by: Robb Glasser <rglasser@google.com> Git-repo: https://android.googlesource.com/kernel/msm Git-commit: 8bc3ec7 Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
This likely breaks tracing tools like trace-cmd. It logs in the same format but now addresses are all 0x0. Bug: 34277115 Change-Id: Ifb0d4d2a184bf0d95726de05b1acee0287a375d9 Git-repo: https://android.googlesource.com/kernel/msm Git-commit: 9ad8f2c Signed-off-by: Srinivasa Rao Kuppala <srkupp@codeaurora.org>
Currently kill_fasync() is called outside the stream lock in snd_pcm_period_elapsed(). This is potentially racy, since the stream may get released even during the irq handler is running. Although snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't guarantee that the irq handler finishes, thus the kill_fasync() call outside the stream spin lock may be invoked after the substream is detached, as recently reported by KASAN. As a quick workaround, move kill_fasync() call inside the stream lock. The fasync is rarely used interface, so this shouldn't have a big impact from the performance POV. Ideally, we should implement some sync mechanism for the proper finish of stream and irq handler. But this oneliner should suffice for most cases, so far. Change-Id: I6e50dfd91d6f8888a089d8bc29e1331c5e013a66 Reported-by: Baozeng Ding <sploving1@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Willy Tarreau <w@1wt.eu> Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Git-commit: a27178e Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
…ranch Change-Id: I8979f085642fae8bf03e1781c229ff09bbee8c66
When user application provides invalid (out of range) stripe size and stripe indices, while submitting requests for the stripe based image processing by the CPP kernel driver, the driver could perform out of bounds access of the internal buffers. This fix ensures that stripe size and indices of frame/command buffer are properly validated during the configuration and before processing such requests through the CPP hardware block. CRs-fixed: 2002207 Change-Id: Ib79e36fb507d8e75d8fc28afb990020a0e1bf845 Signed-off-by: Ravi kumar Koyyana <rkoyyana@codeaurora.org>
…_window" into LA.BF64.1.2.3_rb1.13
…nto LA.BF64.1.2.3_rb1.13
….BF64.1.2.3_rb1.13
…ccess" into LA.BF64.1.2.3_rb1.13
In msm_ispif_is_intf_valid(), we convert a enum variable msm_ispif_vfe_intf, to uint8_t type for validating. This could cause potential issue, if the value is crafted in such a way that lower 8bits pass the validation. Don't use uint8_t as input parm to avoid such vulnerability. CRs-Fixed: 2008469 Change-Id: I4ee400ac0edd830decfbe5712966d968976a268a Signed-off-by: Gaoxiang Chen <gaochen@codeaurora.org>
When allocating userspace memory keep reference to memory allocation till it is completely initialized and info is send back to userspace Change-Id: Id72c82bf98c094ecbd4722813c732a998dcbb188 Signed-off-by: Tarun Karra <tkarra@codeaurora.org> Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>
When the Camera application exercises the V4L2 ioctl operations, CPP driver would attempt to the copy user space buffer contents into the internal kernel buffer. If an invalid length of the user space buffer is passed onto the driver, it could trigger buffer overflow condition. Thus, fix this by copying user space buffer contents into kernel space buffer of the driver for further processing, only after checking for proper length of user space buffer. CRs-fixed: 2025367 Change-Id: I85cf4a961884c7bb0d036299b886044aef7baf7c Signed-off-by: Ravi kumar Koyyana <rkoyyana@codeaurora.org>
… into LA.BF64.1.2.3_rb1.13
… into LA.BF64.1.2.3_rb1.13
randomhydrosol
pushed a commit
that referenced
this pull request
Jun 16, 2017
commit 45caeaa upstream. As Eric Dumazet pointed out this also needs to be fixed in IPv6. v2: Contains the IPv6 tcp/Ipv6 dccp patches as well. We have seen a few incidents lately where a dst_enty has been freed with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that dst_entry. If the conditions/timings are right a crash then ensues when the freed dst_entry is referenced later on. A Common crashing back trace is: #8 [] page_fault at ffffffff8163e648 [exception RIP: __tcp_ack_snd_check+74] . . #9 [] tcp_rcv_established at ffffffff81580b64 #10 [] tcp_v4_do_rcv at ffffffff8158b54a #11 [] tcp_v4_rcv at ffffffff8158cd02 #12 [] ip_local_deliver_finish at ffffffff815668f4 #13 [] ip_local_deliver at ffffffff81566bd9 #14 [] ip_rcv_finish at ffffffff8156656d #15 [] ip_rcv at ffffffff81566f06 #16 [] __netif_receive_skb_core at ffffffff8152b3a2 #17 [] __netif_receive_skb at ffffffff8152b608 #18 [] netif_receive_skb at ffffffff8152b690 #19 [] vmxnet3_rq_rx_complete at ffffffffa015eeaf [vmxnet3] #20 [] vmxnet3_poll_rx_only at ffffffffa015f32a [vmxnet3] #21 [] net_rx_action at ffffffff8152bac2 #22 [] __do_softirq at ffffffff81084b4f #23 [] call_softirq at ffffffff8164845c #24 [] do_softirq at ffffffff81016fc5 #25 [] irq_exit at ffffffff81084ee5 #26 [] do_IRQ at ffffffff81648ff8 Of course it may happen with other NIC drivers as well. It's found the freed dst_entry here: 224 static bool tcp_in_quickack_mode(struct sock *sk)� 225 {� 226 � const struct inet_connection_sock *icsk = inet_csk(sk);� 227 � const struct dst_entry *dst = __sk_dst_get(sk);� 228 � 229 � return (dst && dst_metric(dst, RTAX_QUICKACK)) ||� 230 � � (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);� 231 }� But there are other backtraces attributed to the same freed dst_entry in netfilter code as well. All the vmcores showed 2 significant clues: - Remote hosts behind the default gateway had always been redirected to a different gateway. A rtable/dst_entry will be added for that host. Making more dst_entrys with lower reference counts. Making this more probable. - All vmcores showed a postitive LockDroppedIcmps value, e.g: LockDroppedIcmps 267 A closer look at the tcp_v4_err() handler revealed that do_redirect() will run regardless of whether user space has the socket locked. This can result in a race condition where the same dst_entry cached in sk->sk_dst_entry can be decremented twice for the same socket via: do_redirect()->__sk_dst_check()-> dst_release(). Which leads to the dst_entry being prematurely freed with another socket pointing to it via sk->sk_dst_cache and a subsequent crash. To fix this skip do_redirect() if usespace has the socket locked. Instead let the redirect take place later when user space does not have the socket locked. The dccp/IPv6 code is very similar in this respect, so fixing it there too. As Eric Garver pointed out the following commit now invalidates routes. Which can set the dst->obsolete flag so that ipv4_dst_check() returns null and triggers the dst_release(). Fixes: ceb3320 ("ipv4: Kill routes during PMTU/redirect updates.") Cc: Eric Garver <egarver@redhat.com> Cc: Hannes Sowa <hsowa@redhat.com> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Willy Tarreau <w@1wt.eu>
randomhydrosol
pushed a commit
that referenced
this pull request
Jun 18, 2017
…antiated commit 3c2e226 upstream. arm:pxa_defconfig can result in the following crash if the max1111 driver is not instantiated. Unhandled fault: page domain fault (0x01b) at 0x00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: : 1b [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 300 Comm: kworker/0:1 Not tainted 4.5.0-01301-g1701f680407c #10 Hardware name: SHARP Akita Workqueue: events sharpsl_charge_toggle task: c390a000 ti: c391e000 task.ti: c391e000 PC is at max1111_read_channel+0x20/0x30 LR is at sharpsl_pm_pxa_read_max1111+0x2c/0x3c pc : [<c03aaab0>] lr : [<c0024b50>] psr: 20000013 ... [<c03aaab0>] (max1111_read_channel) from [<c0024b50>] (sharpsl_pm_pxa_read_max1111+0x2c/0x3c) [<c0024b50>] (sharpsl_pm_pxa_read_max1111) from [<c00262e0>] (spitzpm_read_devdata+0x5c/0xc4) [<c00262e0>] (spitzpm_read_devdata) from [<c0024094>] (sharpsl_check_battery_temp+0x78/0x110) [<c0024094>] (sharpsl_check_battery_temp) from [<c0024f9c>] (sharpsl_charge_toggle+0x48/0x110) [<c0024f9c>] (sharpsl_charge_toggle) from [<c004429c>] (process_one_work+0x14c/0x48c) [<c004429c>] (process_one_work) from [<c0044618>] (worker_thread+0x3c/0x5d4) [<c0044618>] (worker_thread) from [<c004a238>] (kthread+0xd0/0xec) [<c004a238>] (kthread) from [<c000a670>] (ret_from_fork+0x14/0x24) This can occur because the SPI controller driver (SPI_PXA2XX) is built as module and thus not necessarily loaded. While building SPI_PXA2XX into the kernel would make the problem disappear, it appears prudent to ensure that the driver is instantiated before accessing its data structures. Cc: Arnd Bergmann <arnd@arndb.de> Cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Willy Tarreau <w@1wt.eu>
randomhydrosol
pushed a commit
that referenced
this pull request
Jun 18, 2017
commit 45caeaa upstream. As Eric Dumazet pointed out this also needs to be fixed in IPv6. v2: Contains the IPv6 tcp/Ipv6 dccp patches as well. We have seen a few incidents lately where a dst_enty has been freed with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that dst_entry. If the conditions/timings are right a crash then ensues when the freed dst_entry is referenced later on. A Common crashing back trace is: #8 [] page_fault at ffffffff8163e648 [exception RIP: __tcp_ack_snd_check+74] . . #9 [] tcp_rcv_established at ffffffff81580b64 #10 [] tcp_v4_do_rcv at ffffffff8158b54a #11 [] tcp_v4_rcv at ffffffff8158cd02 #12 [] ip_local_deliver_finish at ffffffff815668f4 #13 [] ip_local_deliver at ffffffff81566bd9 #14 [] ip_rcv_finish at ffffffff8156656d #15 [] ip_rcv at ffffffff81566f06 #16 [] __netif_receive_skb_core at ffffffff8152b3a2 #17 [] __netif_receive_skb at ffffffff8152b608 #18 [] netif_receive_skb at ffffffff8152b690 #19 [] vmxnet3_rq_rx_complete at ffffffffa015eeaf [vmxnet3] #20 [] vmxnet3_poll_rx_only at ffffffffa015f32a [vmxnet3] #21 [] net_rx_action at ffffffff8152bac2 #22 [] __do_softirq at ffffffff81084b4f #23 [] call_softirq at ffffffff8164845c #24 [] do_softirq at ffffffff81016fc5 #25 [] irq_exit at ffffffff81084ee5 #26 [] do_IRQ at ffffffff81648ff8 Of course it may happen with other NIC drivers as well. It's found the freed dst_entry here: 224 static bool tcp_in_quickack_mode(struct sock *sk)� 225 {� 226 � const struct inet_connection_sock *icsk = inet_csk(sk);� 227 � const struct dst_entry *dst = __sk_dst_get(sk);� 228 � 229 � return (dst && dst_metric(dst, RTAX_QUICKACK)) ||� 230 � � (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);� 231 }� But there are other backtraces attributed to the same freed dst_entry in netfilter code as well. All the vmcores showed 2 significant clues: - Remote hosts behind the default gateway had always been redirected to a different gateway. A rtable/dst_entry will be added for that host. Making more dst_entrys with lower reference counts. Making this more probable. - All vmcores showed a postitive LockDroppedIcmps value, e.g: LockDroppedIcmps 267 A closer look at the tcp_v4_err() handler revealed that do_redirect() will run regardless of whether user space has the socket locked. This can result in a race condition where the same dst_entry cached in sk->sk_dst_entry can be decremented twice for the same socket via: do_redirect()->__sk_dst_check()-> dst_release(). Which leads to the dst_entry being prematurely freed with another socket pointing to it via sk->sk_dst_cache and a subsequent crash. To fix this skip do_redirect() if usespace has the socket locked. Instead let the redirect take place later when user space does not have the socket locked. The dccp/IPv6 code is very similar in this respect, so fixing it there too. As Eric Garver pointed out the following commit now invalidates routes. Which can set the dst->obsolete flag so that ipv4_dst_check() returns null and triggers the dst_release(). Fixes: ceb3320 ("ipv4: Kill routes during PMTU/redirect updates.") Cc: Eric Garver <egarver@redhat.com> Cc: Hannes Sowa <hsowa@redhat.com> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Willy Tarreau <w@1wt.eu>
randomhydrosol
pushed a commit
that referenced
this pull request
Jul 6, 2017
commit 45caeaa upstream. As Eric Dumazet pointed out this also needs to be fixed in IPv6. v2: Contains the IPv6 tcp/Ipv6 dccp patches as well. We have seen a few incidents lately where a dst_enty has been freed with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that dst_entry. If the conditions/timings are right a crash then ensues when the freed dst_entry is referenced later on. A Common crashing back trace is: #8 [] page_fault at ffffffff8163e648 [exception RIP: __tcp_ack_snd_check+74] . . #9 [] tcp_rcv_established at ffffffff81580b64 #10 [] tcp_v4_do_rcv at ffffffff8158b54a #11 [] tcp_v4_rcv at ffffffff8158cd02 #12 [] ip_local_deliver_finish at ffffffff815668f4 #13 [] ip_local_deliver at ffffffff81566bd9 #14 [] ip_rcv_finish at ffffffff8156656d #15 [] ip_rcv at ffffffff81566f06 #16 [] __netif_receive_skb_core at ffffffff8152b3a2 #17 [] __netif_receive_skb at ffffffff8152b608 #18 [] netif_receive_skb at ffffffff8152b690 #19 [] vmxnet3_rq_rx_complete at ffffffffa015eeaf [vmxnet3] #20 [] vmxnet3_poll_rx_only at ffffffffa015f32a [vmxnet3] #21 [] net_rx_action at ffffffff8152bac2 #22 [] __do_softirq at ffffffff81084b4f #23 [] call_softirq at ffffffff8164845c #24 [] do_softirq at ffffffff81016fc5 #25 [] irq_exit at ffffffff81084ee5 #26 [] do_IRQ at ffffffff81648ff8 Of course it may happen with other NIC drivers as well. It's found the freed dst_entry here: 224 static bool tcp_in_quickack_mode(struct sock *sk)� 225 {� 226 � const struct inet_connection_sock *icsk = inet_csk(sk);� 227 � const struct dst_entry *dst = __sk_dst_get(sk);� 228 � 229 � return (dst && dst_metric(dst, RTAX_QUICKACK)) ||� 230 � � (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);� 231 }� But there are other backtraces attributed to the same freed dst_entry in netfilter code as well. All the vmcores showed 2 significant clues: - Remote hosts behind the default gateway had always been redirected to a different gateway. A rtable/dst_entry will be added for that host. Making more dst_entrys with lower reference counts. Making this more probable. - All vmcores showed a postitive LockDroppedIcmps value, e.g: LockDroppedIcmps 267 A closer look at the tcp_v4_err() handler revealed that do_redirect() will run regardless of whether user space has the socket locked. This can result in a race condition where the same dst_entry cached in sk->sk_dst_entry can be decremented twice for the same socket via: do_redirect()->__sk_dst_check()-> dst_release(). Which leads to the dst_entry being prematurely freed with another socket pointing to it via sk->sk_dst_cache and a subsequent crash. To fix this skip do_redirect() if usespace has the socket locked. Instead let the redirect take place later when user space does not have the socket locked. The dccp/IPv6 code is very similar in this respect, so fixing it there too. As Eric Garver pointed out the following commit now invalidates routes. Which can set the dst->obsolete flag so that ipv4_dst_check() returns null and triggers the dst_release(). Fixes: ceb3320 ("ipv4: Kill routes during PMTU/redirect updates.") Cc: Eric Garver <egarver@redhat.com> Cc: Hannes Sowa <hsowa@redhat.com> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Willy Tarreau <w@1wt.eu>
randomhydrosol
pushed a commit
that referenced
this pull request
Jul 27, 2017
commit 45caeaa upstream. As Eric Dumazet pointed out this also needs to be fixed in IPv6. v2: Contains the IPv6 tcp/Ipv6 dccp patches as well. We have seen a few incidents lately where a dst_enty has been freed with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that dst_entry. If the conditions/timings are right a crash then ensues when the freed dst_entry is referenced later on. A Common crashing back trace is: #8 [] page_fault at ffffffff8163e648 [exception RIP: __tcp_ack_snd_check+74] . . #9 [] tcp_rcv_established at ffffffff81580b64 #10 [] tcp_v4_do_rcv at ffffffff8158b54a #11 [] tcp_v4_rcv at ffffffff8158cd02 #12 [] ip_local_deliver_finish at ffffffff815668f4 #13 [] ip_local_deliver at ffffffff81566bd9 #14 [] ip_rcv_finish at ffffffff8156656d #15 [] ip_rcv at ffffffff81566f06 #16 [] __netif_receive_skb_core at ffffffff8152b3a2 #17 [] __netif_receive_skb at ffffffff8152b608 #18 [] netif_receive_skb at ffffffff8152b690 #19 [] vmxnet3_rq_rx_complete at ffffffffa015eeaf [vmxnet3] #20 [] vmxnet3_poll_rx_only at ffffffffa015f32a [vmxnet3] #21 [] net_rx_action at ffffffff8152bac2 #22 [] __do_softirq at ffffffff81084b4f #23 [] call_softirq at ffffffff8164845c #24 [] do_softirq at ffffffff81016fc5 #25 [] irq_exit at ffffffff81084ee5 #26 [] do_IRQ at ffffffff81648ff8 Of course it may happen with other NIC drivers as well. It's found the freed dst_entry here: 224 static bool tcp_in_quickack_mode(struct sock *sk)� 225 {� 226 � const struct inet_connection_sock *icsk = inet_csk(sk);� 227 � const struct dst_entry *dst = __sk_dst_get(sk);� 228 � 229 � return (dst && dst_metric(dst, RTAX_QUICKACK)) ||� 230 � � (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);� 231 }� But there are other backtraces attributed to the same freed dst_entry in netfilter code as well. All the vmcores showed 2 significant clues: - Remote hosts behind the default gateway had always been redirected to a different gateway. A rtable/dst_entry will be added for that host. Making more dst_entrys with lower reference counts. Making this more probable. - All vmcores showed a postitive LockDroppedIcmps value, e.g: LockDroppedIcmps 267 A closer look at the tcp_v4_err() handler revealed that do_redirect() will run regardless of whether user space has the socket locked. This can result in a race condition where the same dst_entry cached in sk->sk_dst_entry can be decremented twice for the same socket via: do_redirect()->__sk_dst_check()-> dst_release(). Which leads to the dst_entry being prematurely freed with another socket pointing to it via sk->sk_dst_cache and a subsequent crash. To fix this skip do_redirect() if usespace has the socket locked. Instead let the redirect take place later when user space does not have the socket locked. The dccp/IPv6 code is very similar in this respect, so fixing it there too. As Eric Garver pointed out the following commit now invalidates routes. Which can set the dst->obsolete flag so that ipv4_dst_check() returns null and triggers the dst_release(). Fixes: ceb3320 ("ipv4: Kill routes during PMTU/redirect updates.") Cc: Eric Garver <egarver@redhat.com> Cc: Hannes Sowa <hsowa@redhat.com> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Willy Tarreau <w@1wt.eu>
randomhydrosol
pushed a commit
that referenced
this pull request
Apr 12, 2019
commit fa30dde38aa8628c73a6dded7cb0bba38c27b576 upstream. We see the following NULL pointer dereference while running xfstests generic/475: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 PGD 8000000c84bad067 P4D 8000000c84bad067 PUD c84e62067 PMD 0 Oops: 0000 [#1] SMP PTI CPU: 7 PID: 9886 Comm: fsstress Kdump: loaded Not tainted 5.0.0-rc8 #10 RIP: 0010:ext4_do_update_inode+0x4ec/0x760 ... Call Trace: ? jbd2_journal_get_write_access+0x42/0x50 ? __ext4_journal_get_write_access+0x2c/0x70 ? ext4_truncate+0x186/0x3f0 ext4_mark_iloc_dirty+0x61/0x80 ext4_mark_inode_dirty+0x62/0x1b0 ext4_truncate+0x186/0x3f0 ? unmap_mapping_pages+0x56/0x100 ext4_setattr+0x817/0x8b0 notify_change+0x1df/0x430 do_truncate+0x5e/0x90 ? generic_permission+0x12b/0x1a0 This is triggered because the NULL pointer handle->h_transaction was dereferenced in function ext4_update_inode_fsync_trans(). I found that the h_transaction was set to NULL in jbd2__journal_restart but failed to attached to a new transaction while the journal is aborted. Fix this by checking the handle before updating the inode. Fixes: b436b9b ("ext4: Wait for proper transaction commit on fsync") Change-Id: Iee3dc696da373f765f1afc46d43033cc66a7e828 Signed-off-by: Jiufei Xue <jiufei.xue@linux.alibaba.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.