- 14 Aug, 2018 8 commits
-
-
shankai authored
Revert "futex: Prevent overflow by strengthen input validation" This reverts commit 4f7ca96309409d1b928c11614ae7f66739fc6bac. Change-Id: I9ccbb17b3866f532a7241aa1430a9a787d80127c (cherry picked from commit 2dae2be5a2fe04456973d4dc40b05d3604c59e72) (cherry picked from commit 8d1b38a28a1997bea474810369b516e5b467e30b)
-
liuhaituo authored
Move rx_worker in irq handler. Change-Id: Ibb791a1401b19777393ab2ecbecade27bcfe89a9 (cherry picked from commit fb523fcd7c1883bc43c117ff4f86788fa40a753e)
-
guozhiming authored
Merge Qualcomm patches Change-Id: I2e3faaa4d523ccc0a4b7afda15827ce51b2231d2
-
xiaoxiaohuan authored
Modify dtsi file. Change-Id: Ia7ba83cdf9236384af3d5d9e36d5ae85e08cd498 (cherry picked from commit 8d13da656ee4e6a590bedcff65b7831c2b26c44d)
-
xiaoxiaohuan authored
Clear unrecovered as GMU start is successful. Change-Id: If857209c155f3980895344f8c209fd8db7cfb4a2 (cherry picked from commit 3f235b7fd36497a4181dc32dabe85fd99e78a65c)
-
casey.song authored
Call flush_workqueue. Change-Id: Iab0461097ed04e1334f21225776194c312454712 (cherry picked from commit b0b0b2210c0c4348fed33eda836f73135e26b138)
-
Liu Qinghua authored
Modify QMI_SERVREG_LOC_SERVER_TIMEOUT Change-Id: I2868e7c12110c904adddc39cef97844fb14442fd Signed-off-by:Liu Qinghua <collins.liu@oneplus.net>
-
Li Jinyue authored
UBSAN reports signed integer overflow in kernel/futex.c: UBSAN: Undefined behaviour in kernel/futex.c:2041:18 signed integer overflow: 0 - -2147483648 cannot be represented in type 'int' Add a sanity check to catch negative values of nr_wake and nr_requeue. Change-Id: I56ffeca62bedf7f57047119faeaefc9665854dbf Signed-off-by:
Li Jinyue <lijinyue@huawei.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: peterz@infradead.org Cc: dvhart@infradead.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/1513242294-31786-1-git-send-email-lijinyue@huawei.com (cherry picked from commit dcbbf4fda5eb76e2e69cd516d18f68ccd5f85a0d) (cherry picked from commit ff698f317a7de6bf56f8813634a8716303742605)
-
- 17 Jul, 2018 20 commits
-
-
guozhiming authored
solve Kernel Panic-sde_encoder_input_event_handler issue Change-Id: I47d91480743e40d5742ad203a7fae3b6f92f38c3
-
wujialong authored
battery_supply_callback() will call bcl_usb_process() which will access tz_dev, but the initialization of tz_dev is after the register of battery_supply_callback. So, it's possible that tz_dev is accessed without initialize. Change the code sequence to avoid this issue. Change-Id: Iba60ce16de266723224a7058af3b58058a01dc3b
-
yangfangbiao authored
During Dash charge,there is a unexpected read FG ,this will casue Dash abnormal,so use another API to read FG,so than DASH can contrl Fg read/write Change-Id: I15c036b77cd98c025c86e778c1e4fbe3f08bce95
-
zhouhanxin authored
merge qualcomm cr2223189 patch Change-Id: If8f65e74d2024b8a6bd1374986797748182a3080
-
songyutao authored
The CPAS interrupts are for debug purpose, they provide debugging information when something went wrong at hw level (for exa - smmu error, ubwc error).. so disabling CPAS IRQs mean, we will not get those information through CAMNOC (there are already other ways to get smmu fault information). It won’t break any working functionality. Change-Id: Ib37d83a5449b7ca53ea18ee33fa2629a092c4bdb
-
xunanbin authored
Change-Id: I1d3e240ca322408d57fdafcdf62e31f3b9c6c555
-
wujialong authored
Some irq wakeup without irq number print, Add patch to print wakeup irq Change-Id: Ibd4b0162b9f998331109b27c95c5d254d71dde7a
-
casey.song authored
Change-Id: I645f695ac2c3fb1ec9be5f158e1783136e20dec3
-
xibao authored
Change-Id: Icb6768cea7e8f00c16697559f4a36ae8f19ed59a
-
yangfangbiao authored
If battery level bigger than 7%,when probe schedule a work 16s to supend usb and keep 1s. Change-Id: I20c4383243fa988e1d2985904f63e0fb059c15e8
-
songyutao authored
camera: isp: acquire tasklet cmd before processing top half Acquire tasklet cmd before processing IRQ so that none resource is allocated unless IRQ can be scheduled to tasklet. . Change-Id: I724d3896add168cb8db883e5ffa70e3b107794b1
-
yangfangbiao authored
Set Ichg of FLOAT to 1A first,after redetect type it also FLOAT will set 1.5A Change-Id: Ib9bcde6af0346451c225e93fe607152250e5e414
-
hecaiqiang authored
If we echo 1 > /sys/class/leds/led:torch_1/brightness the final reg value will set 0x7f, because the reg value is u8 type, it get a '-1' value, we should avoid this value be assigned to reg. The previous commit(if the ires_ua have point value in mA, will have this problem): Change-Id: I3835aa6ae681e6471850281b1de6bbb4d90753ce
-
shankai authored
make sure we only free the number of configurations and interfaces that we could have allocated. Change-Id: I4d5d228bae0aba15be13052dfaf609443c53f96a
-
shankai authored
When the request_key() syscall is not passed a destination keyring, it links the requested key (if constructed) into the "default" request-key keyring. This should require Write permission to the keyring. However, there is actually no permission check. This can be abused to add keys to any keyring to which only Search permission is granted. This is because Search permission allows joining the keyring. keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_SESSION_KEYRING) then will set the default request-key keyring to the session keyring. Then, request_key() can be used to add keys to the keyring. Both negatively and positively instantiated keys can be added using this method. Adding negative keys is trivial. Adding a positive key is a bit trickier. It requires that either /sbin/request-key positively instantiates the key, or that another thread adds the key to the process keyring at just the right time, such that request_key() misses it initially but then finds it in construct_alloc_key(). Fix this bug by checking for Write permission to the keyring in construct_get_dest_keyring() when the default keyring is being used. We don't do the permission check for non-default keyrings because that was already done by the earlier call to lookup_user_key(). Also, request_key_and_link() is currently passed a 'struct key *' rather than a key_ref_t, so the "possessed" bit is unavailable. We also don't do the permission check for the "requestor keyring", to continue to support the use case described by commit 8bbf4976 ("KEYS: Alter use of key instantiation link-to-keyring argument") where /sbin/request-key recursively calls request_key() to add keys to the original requestor's destination keyring. (I don't know of any users who actually do that, though...) Fixes: 3e30148c ("[PATCH] Keys: Make request-key create an authorisation key") Cc: <stable@vger.kernel.org> # v2.6.13+ Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
David Howells <dhowells@redhat.com> Type:PATCH Test:no * Change-Id: Ieb40176a0d1131a58ede0afc6caf43dcd0c5e404 (cherry picked from commit 72eb8cab03b8b9112b8b1faf7c254390ce613550) (cherry picked from commit b7f02bd45dbff460d3736350bf1f9ff056a9f755)
-
shankai authored
Because the HMAC template didn't check that its underlying hash algorithm is unkeyed, trying to use "hmac(hmac(sha3-512-generic))" through AF_ALG or through KEYCTL_DH_COMPUTE resulted in the inner HMAC being used without having been keyed, resulting in sha3_update() being called without sha3_init(), causing a stack buffer overflow. This is a very old bug, but it seems to have only started causing real problems when SHA-3 support was added (requires CONFIG_CRYPTO_SHA3) because the innermost hash's state is ->import()ed from a zeroed buffer, and it just so happens that other hash algorithms are fine with that, but SHA-3 is not. However, there could be arch or hardware-dependent hash algorithms also affected; I couldn't test everything. Fix the bug by introducing a function crypto_shash_alg_has_setkey() which tests whether a shash algorithm is keyed. Then update the HMAC template to require that its underlying hash algorithm is unkeyed. Here is a reproducer: #include <linux/if_alg.h> #include <sys/socket.h> int main() { int algfd; struct sockaddr_alg addr = { .salg_type = "hash", .salg_name = "hmac(hmac(sha3-512-generic))", }; char key[4096] = { 0 }; algfd = socket(AF_ALG, SOCK_SEQPACKET, 0); bind(algfd, (const struct sockaddr *)&addr, sizeof(addr)); setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key)); } Here was the KASAN report from syzbot: BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:341 [inline] BUG: KASAN: stack-out-of-bounds in sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161 Write of size 4096 at addr ffff8801cca07c40 by task syzkaller076574/3044 CPU: 1 PID: 3044 Comm: syzkaller076574 Not tainted 4.14.0-mm1+ #25 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 print_address_description+0x73/0x250 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 [inline] kasan_report+0x25b/0x340 mm/kasan/report.c:409 check_memory_region_inline mm/kasan/kasan.c:260 [inline] check_memory_region+0x137/0x190 mm/kasan/kasan.c:267 memcpy+0x37/0x50 mm/kasan/kasan.c:303 memcpy include/linux/string.h:341 [inline] sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161 crypto_shash_update+0xcb/0x220 crypto/shash.c:109 shash_finup_unaligned+0x2a/0x60 crypto/shash.c:151 crypto_shash_finup+0xc4/0x120 crypto/shash.c:165 hmac_finup+0x182/0x330 crypto/hmac.c:152 crypto_shash_finup+0xc4/0x120 crypto/shash.c:165 shash_digest_unaligned+0x9e/0xd0 crypto/shash.c:172 crypto_shash_digest+0xc4/0x120 crypto/shash.c:186 hmac_setkey+0x36a/0x690 crypto/hmac.c:66 crypto_shash_setkey+0xad/0x190 crypto/shash.c:64 shash_async_setkey+0x47/0x60 crypto/shash.c:207 crypto_ahash_setkey+0xaf/0x180 crypto/ahash.c:200 hash_setkey+0x40/0x90 crypto/algif_hash.c:446 alg_setkey crypto/af_alg.c:221 [inline] alg_setsockopt+0x2a1/0x350 crypto/af_alg.c:254 SYSC_setsockopt net/socket.c:1851 [inline] SyS_setsockopt+0x189/0x360 net/socket.c:1830 entry_SYSCALL_64_fastpath+0x1f/0x96 Reported-by:syzbot <syzkaller@googlegroups.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Type:PATCH Test:no need * Change-Id: Iaaede33f2a91add27679f17a6c7b97c32483ef9c (cherry picked from commit 306ceebd6fa1e1ac98894740f9dbd33dac101505) (cherry picked from commit 7f33695261961c004fdeed7dbbd5bb35607126b9)
-
Li Jinyue authored
UBSAN reports signed integer overflow in kernel/futex.c: UBSAN: Undefined behaviour in kernel/futex.c:2041:18 signed integer overflow: 0 - -2147483648 cannot be represented in type 'int' Add a sanity check to catch negative values of nr_wake and nr_requeue. Change-Id: I80b3281a038434dc752017229afa2e91818de9e1 Signed-off-by:
Li Jinyue <lijinyue@huawei.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: peterz@infradead.org Cc: dvhart@infradead.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/1513242294-31786-1-git-send-email-lijinyue@huawei.com (cherry picked from commit 4f7ca96309409d1b928c11614ae7f66739fc6bac) (cherry picked from commit a99fb454588cf4977e51a67ddc0bafce918bb9b5)
-
Florian Westphal authored
The rationale for removing the check is only correct for rulesets generated by ip(6)tables. In iptables, a jump can only occur to a user-defined chain, i.e. because we size the stack based on number of user-defined chains we cannot exceed stack size. However, the underlying binary format has no such restriction, and the validation step only ensures that the jump target is a valid rule start point. IOW, its possible to build a rule blob that has no user-defined chains but does contain a jump. If this happens, no jump stack gets allocated and crash occurs because no jumpstack was allocated. Type:PATCH Test:no need test Change-Id: I3fbc7352ab6ce82d10a2a8f6b3e70548a7dd3cce Fixes: 7814b6ec ("netfilter: xtables: don't save/restore jumpstack offset") Reported-by: syzbot+e783f671527912cd9403@syzkaller.appspotmail.com Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 9d94c3287eb0e6cba8b71628e14e8702cddee985) (cherry picked from commit aed47ad3d9e78e2decfbed1f94a73c59e6c9a667)
-
Yunsheng Lin authored
skb maybe freed in hns_nic_net_xmit_hw() and return NETDEV_TX_OK, which cause hns_nic_net_xmit to use a freed skb. BUG: KASAN: use-after-free in hns_nic_net_xmit_hw+0x62c/0x940... [17659.112635] alloc_debug_processing+0x18c/0x1a0 [17659.117208] __slab_alloc+0x52c/0x560 [17659.120909] kmem_cache_alloc_node+0xac/0x2c0 [17659.125309] __alloc_skb+0x6c/0x260 [17659.128837] tcp_send_ack+0x8c/0x280 [17659.132449] __tcp_ack_snd_check+0x9c/0xf0 [17659.136587] tcp_rcv_established+0x5a4/0xa70 [17659.140899] tcp_v4_do_rcv+0x27c/0x620 [17659.144687] tcp_prequeue_process+0x108/0x170 [17659.149085] tcp_recvmsg+0x940/0x1020 [17659.152787] inet_recvmsg+0x124/0x180 [17659.156488] sock_recvmsg+0x64/0x80 [17659.160012] SyS_recvfrom+0xd8/0x180 [17659.163626] __sys_trace_return+0x0/0x4 [17659.167506] INFO: Freed in kfree_skbmem+0xa0/0xb0 age=23 cpu=1 pid=13 [17659.174000] free_debug_processing+0x1d4/0x2c0 [17659.178486] __slab_free+0x240/0x390 [17659.182100] kmem_cache_free+0x24c/0x270 [17659.186062] kfree_skbmem+0xa0/0xb0 [17659.189587] __kfree_skb+0x28/0x40 [17659.193025] napi_gro_receive+0x168/0x1c0 [17659.197074] hns_nic_rx_up_pro+0x58/0x90 [17659.201038] hns_nic_rx_poll_one+0x518/0xbc0 [17659.205352] hns_nic_common_poll+0x94/0x140 [17659.209576] net_rx_action+0x458/0x5e0 [17659.213363] __do_softirq+0x1b8/0x480 [17659.217062] run_ksoftirqd+0x64/0x80 [17659.220679] smpboot_thread_fn+0x224/0x310 [17659.224821] kthread+0x150/0x170 [17659.228084] ret_from_fork+0x10/0x40 BUG: KASAN: use-after-free in hns_nic_net_xmit+0x8c/0xc0... [17751.080490] __slab_alloc+0x52c/0x560 [17751.084188] kmem_cache_alloc+0x244/0x280 [17751.088238] __build_skb+0x40/0x150 [17751.091764] build_skb+0x28/0x100 [17751.095115] __alloc_rx_skb+0x94/0x150 [17751.098900] __napi_alloc_skb+0x34/0x90 [17751.102776] hns_nic_rx_poll_one+0x180/0xbc0 [17751.107097] hns_nic_common_poll+0x94/0x140 [17751.111333] net_rx_action+0x458/0x5e0 [17751.115123] __do_softirq+0x1b8/0x480 [17751.118823] run_ksoftirqd+0x64/0x80 [17751.122437] smpboot_thread_fn+0x224/0x310 [17751.126575] kthread+0x150/0x170 [17751.129838] ret_from_fork+0x10/0x40 [17751.133454] INFO: Freed in kfree_skbmem+0xa0/0xb0 age=19 cpu=7 pid=43 [17751.139951] free_debug_processing+0x1d4/0x2c0 [17751.144436] __slab_free+0x240/0x390 [17751.148051] kmem_cache_free+0x24c/0x270 [17751.152014] kfree_skbmem+0xa0/0xb0 [17751.155543] __kfree_skb+0x28/0x40 [17751.159022] napi_gro_receive+0x168/0x1c0 [17751.163074] hns_nic_rx_up_pro+0x58/0x90 [17751.167041] hns_nic_rx_poll_one+0x518/0xbc0 [17751.171358] hns_nic_common_poll+0x94/0x140 [17751.175585] net_rx_action+0x458/0x5e0 [17751.179373] __do_softirq+0x1b8/0x480 [17751.183076] run_ksoftirqd+0x64/0x80 [17751.186691] smpboot_thread_fn+0x224/0x310 [17751.190826] kthread+0x150/0x170 [17751.194093] ret_from_fork+0x10/0x40 Change-Id: I2931a0bf5e757814e28942ffa45c72f510cd9bdf Fixes: 13ac695e ("net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem") Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by:
lipeng <lipeng321@huawei.com> Reported-by:
Jun He <hjat2005@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit fecf2a1bc99eb9fe9f9f7384960416b428537f2f) (cherry picked from commit 1a04ddb7106215fe0a1cc40dd91f05cdf650b3ad)
-
Cong Wang authored
Andrey reported a use-after-free in __ns_get_path(): spin_lock include/linux/spinlock.h:299 [inline] lockref_get_not_dead+0x19/0x80 lib/lockref.c:179 __ns_get_path+0x197/0x860 fs/nsfs.c:66 open_related_ns+0xda/0x200 fs/nsfs.c:143 sock_ioctl+0x39d/0x440 net/socket.c:1001 vfs_ioctl fs/ioctl.c:45 [inline] do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685 SYSC_ioctl fs/ioctl.c:700 [inline] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691 We are under rcu read lock protection at that point: rcu_read_lock(); d = atomic_long_read(&ns->stashed); if (!d) goto slow; dentry = (struct dentry *)d; if (!lockref_get_not_dead(&dentry->d_lockref)) goto slow; rcu_read_unlock(); but don't use a proper RCU API on the free path, therefore a parallel __d_free() could free it at the same time. We need to mark the stashed dentry with DCACHE_RCUACCESS so that __d_free() will be called after all readers leave RCU. Change-Id: I4c0a578b3b4c5769ff757962ecae93cdf71dcef9 Fixes: e149ed2b ("take the targets of /proc/*/ns/* symlinks to separate fs") Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Reported-by:Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Git-commit: 073c516ff73557a8f7315066856c04b50383ac34 Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gitSigned-off-by:
Chintan Pandya <cpandya@codeaurora.org> (cherry picked from commit e67d4e4c59b834be47f3493a1055a6aa120ae4ab) (cherry picked from commit 79469c53a1ed397e9e320d9dd7ad75f893b03436)
-
- 18 Jun, 2018 1 commit
-
-
Liu Qinghua authored
disable sdi when turn off download mode even download mode is off, device still can enter dump when noc error happen, it is caused by sdi, so we turn off sdi function when download mode is off Change-Id: I2179118b5e7a3726e63ed8cf5094c969ba7ba016 Signed-off-by:Liu Qinghua <collins.liu@oneplus.net>
-
- 05 Jun, 2018 10 commits
-
-
guoling authored
* Change-Id: Ic26929306257135d28ef686da262960be0f546b7 Signed-off-by:guoling <lynn.guo@oneplus.com> (cherry picked from commit caaff468819479a29a9b14be0336e46cfca21a3b)
-
yangfangbiao authored
Plan: Connect Dash charger to start device,after devcie started,it show DASH charge not start after about 90s it will enter dash charge mode in the end. the reason is that APSD result is wrong,it detect OCP to FLOAT, if the fist time it detected FLOAT we will rerun APSD after 2s,after rerun it also show FLOAT we will switch usb d+ d- to DASH charge ,so that it will enter dash early ,2s instead 90s. Change-Id: I7373f0e759d8b590ad93e035ea194bdb68bdf53d -
rio.zhao authored
* Change-Id: I0f4528a97c653d3403b90223c634bf92c0cdbd7f Signed-off-by:rio.zhao <rio.zhao@oneplus.com> (cherry picked from commit 425aaaee42a6d95b66a1cfc295c0217272b17a34)
-
yankelong authored
Change-Id: I9787371102207b07cdbc9866f3b9d56843dce5ea (cherry picked from commit 3df2fc99bb2d6a34cc1278f5d6620d777443a9be)
-
yangfangbiao authored
Change-Id: Ia97deccc05dda3ac71c1cfe5452ad6effbf0c5f7
-
xieshuangshuang authored
Plan: move crtc caching to encoder_modeset Atomic commit path calls encoder_modeset followed by encoder_enable. Crtc caching within encoder_enable is late for bootup cases because modeset request also need the cached crtc access. Avoid invalid crtc error message by caching at modeset level instead of encoder enable. Change-Id: I908861d37865d8b7a208d566ece40b6a7ffa60ff (cherry picked from commit 15e6aac4669f16bc22f253dc05716ab99ac1e3fb)
-
xibao authored
Fix the issue that APPS struck at RPMH response, core stuck in RscHalCheckAMCFinishedIRQ during modem doing shutdown * Change-Id: I89a1696d16642c3349872b35351ea2b4531578ab (cherry picked from commit 8269ebbe9a82365517f1f06b49d37231195325e2)
-
yangfangbiao authored
Change-Id: I301585254e7cce4eaac18649c9fc506b772ffcb7 (cherry picked from commit 3c487a02671d178fae856a1a80f8145bb38725e5)
-
niqiangbo authored
* Change-Id: I38536704ed2058408b80a24be878129813b1fee0 (cherry picked from commit 8164aac79904fb14e1e9f64bed8513f1794de49b)
-
liuhaituo authored
Change-Id: I5ca0b7fd327b0f4e82ad9ef286f411d948c05c70 (cherry picked from commit e406faed248c37e0b123ef647a4ea5a06cdd99cf)
-
- 19 May, 2018 1 commit
-
-
aaron authored
kernel device tree source code for OnePlus6 O MR1 device
-