- 07 9月, 2022 40 次提交
-
-
由 Jiri Slaby 提交于
stable inclusion from stable-v5.10.134 commit 08afa87f58d83dfe040572ed591b47e8cb9e225c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5A5Y1 CVE: CVE-2022-1462 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=08afa87f58d83dfe040572ed591b47e8cb9e225c -------------------------------- commit a501ab75 upstream. There is a race in pty_write(). pty_write() can be called in parallel with e.g. ioctl(TIOCSTI) or ioctl(TCXONC) which also inserts chars to the buffer. Provided, tty_flip_buffer_push() in pty_write() is called outside the lock, it can commit inconsistent tail. This can lead to out of bounds writes and other issues. See the Link below. To fix this, we have to introduce a new helper called tty_insert_flip_string_and_push_buffer(). It does both tty_insert_flip_string() and tty_flip_buffer_commit() under the port lock. It also calls queue_work(), but outside the lock. See 71a174b3 (pty: do tty_flip_buffer_push without port->lock in pty_write) for the reasons. Keep the helper internal-only (in drivers' tty.h). It is not intended to be used widely. Link: https://seclists.org/oss-sec/2022/q2/155 Fixes: 71a174b3 (pty: do tty_flip_buffer_push without port->lock in pty_write) Cc: 一只狗 <chennbnbnb@gmail.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Suggested-by: NHillf Danton <hdanton@sina.com> Signed-off-by: NJiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220707082558.9250-2-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jiri Slaby 提交于
stable inclusion from stable-v5.10.134 commit a4bb7ef2d6f6d7158539f95b2fa97d658ea3cf75 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5A5Y1 CVE: CVE-2022-1462 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a4bb7ef2d6f6d7158539f95b2fa97d658ea3cf75 -------------------------------- commit 716b1058 upstream. We will need this new helper in the next patch. Cc: Hillf Danton <hdanton@sina.com> Cc: 一只狗 <chennbnbnb@gmail.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NJiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220707082558.9250-1-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jiri Slaby 提交于
stable inclusion from stable-v5.10.134 commit c84986d097451203bb79a8bff8d37e56488fbf1d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5A5Y1 CVE: CVE-2022-1462 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c84986d097451203bb79a8bff8d37e56488fbf1d -------------------------------- commit 5db96ef2 upstream. Since commit a9c3f68f (tty: Fix low_latency BUG) in 2014, tty_flip_buffer_push() is only a wrapper to tty_schedule_flip(). All users were converted in the previous patches, so remove tty_schedule_flip() completely while inlining its body into tty_flip_buffer_push(). One less exported function. Reviewed-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NJiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20211122111648.30379-4-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jiri Slaby 提交于
stable inclusion from stable-v5.10.134 commit 4d374625cca21ce4f9cdd58170d070b400910ae2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5A5Y1 CVE: CVE-2022-1462 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4d374625cca21ce4f9cdd58170d070b400910ae2 -------------------------------- commit b68b9144 upstream. Since commit a9c3f68f (tty: Fix low_latency BUG) in 2014, tty_flip_buffer_push() is only a wrapper to tty_schedule_flip(). We are going to remove the latter (as it is used less), so call the former in the rest of the users. Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: William Hubbs <w.d.hubbs@gmail.com> Cc: Chris Brannon <chris@the-brannons.com> Cc: Kirk Reiser <kirk@reisers.ca> Cc: Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NJiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20211122111648.30379-3-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jiri Slaby 提交于
stable inclusion from stable-v5.10.134 commit 6a81848252869d929354a879e08807c932444929 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5A5Y1 CVE: CVE-2022-1462 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6a81848252869d929354a879e08807c932444929 -------------------------------- commit 5f6a8515 upstream. Since commit a9c3f68f (tty: Fix low_latency BUG) in 2014, tty_flip_buffer_push() is only a wrapper to tty_schedule_flip(). We are going to remove the latter (as it is used less), so call the former in drivers/tty/. Cc: Vladimir Zapolskiy <vz@mleia.com> Reviewed-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NJiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20211122111648.30379-2-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zheng Zengkai 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR -------------------------------- As cd720fad8b57 ("pipe: make poll_usage boolean and annotate its access") makes poll_usage boolean, kabi compatibility is broken for the interfaces using struct pipo_inode_info. Use KABI_REPLACE() to restore kabi compatibility. Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: Nlinan <linan122@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Liu Jian 提交于
stable inclusion from stable-v5.10.120 commit 886eeb046096fec4f7e43ed8fc94974564b868d4 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=886eeb046096fec4f7e43ed8fc94974564b868d4 -------------------------------- commit 45969b41 upstream. The data length of skb frags + frag_list may be greater than 0xffff, and skb_header_pointer can not handle negative offset. So, here INT_MAX is used to check the validity of offset. Add the same change to the related function skb_store_bytes. Fixes: 05c74e5e ("bpf: add bpf_skb_load_bytes helper") Signed-off-by: NLiu Jian <liujian56@huawei.com> Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Acked-by: NSong Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20220416105801.88708-2-liujian56@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Yuntao Wang 提交于
stable inclusion from stable-v5.10.120 commit 7f845de2863334bed4f362e95853f5e7bc323737 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7f845de2863334bed4f362e95853f5e7bc323737 -------------------------------- commit a2aa95b7 upstream. The cnt value in the 'cnt >= BPF_MAX_TRAMP_PROGS' check does not include BPF_TRAMP_MODIFY_RETURN bpf programs, so the number of the attached BPF_TRAMP_MODIFY_RETURN bpf programs in a trampoline can exceed BPF_MAX_TRAMP_PROGS. When this happens, the assignment '*progs++ = aux->prog' in bpf_trampoline_get_progs() will cause progs array overflow as the progs field in the bpf_tramp_progs struct can only hold at most BPF_MAX_TRAMP_PROGS bpf programs. Fixes: 88fd9e53 ("bpf: Refactor trampoline update code") Signed-off-by: NYuntao Wang <ytcoode@gmail.com> Link: https://lore.kernel.org/r/20220430130803.210624-1-ytcoode@gmail.comSigned-off-by: NAlexei Starovoitov <ast@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Chuck Lever 提交于
stable inclusion from stable-v5.10.120 commit 3097f38e91266c7132c3fdb7e778fac858c00670 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3097f38e91266c7132c3fdb7e778fac858c00670 -------------------------------- commit ce3c4ad7 upstream. nfsd4_release_lockowner() holds clp->cl_lock when it calls check_for_locks(). However, check_for_locks() calls nfsd_file_get() / nfsd_file_put() to access the backing inode's flc_posix list, and nfsd_file_put() can sleep if the inode was recently removed. Let's instead rely on the stateowner's reference count to gate whether the release is permitted. This should be a reliable indication of locks-in-use since file lock operations and ->lm_get_owner take appropriate references, which are released appropriately when file locks are removed. Reported-by: NDai Ngo <dai.ngo@oracle.com> Signed-off-by: NChuck Lever <chuck.lever@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Trond Myklebust 提交于
stable inclusion from stable-v5.10.120 commit 78a62e09d88537150ffb31451d07efdc8a1c9b78 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=78a62e09d88537150ffb31451d07efdc8a1c9b78 -------------------------------- commit 45228440 upstream. We need to filter out ENOMEM in nfs_error_is_fatal_on_server(), because running out of memory on our client is not a server error. Reported-by: NOlga Kornievskaia <aglo@umich.edu> Fixes: 2dc23aff ("NFS: ENOMEM should also be a fatal error.") Cc: stable@vger.kernel.org Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Akira Yokosawa 提交于
stable inclusion from stable-v5.10.120 commit 1d100fcc1da7a5baaf29d81d1bfb8e106fc3c297 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1d100fcc1da7a5baaf29d81d1bfb8e106fc3c297 -------------------------------- commit 6d5aa418 upstream. The reference to `explicit_in_reply_to` is pointless as when the reference was added in the form of "#15" [1], Section 15) was "The canonical patch format". The reference of "#15" had not been properly updated in a couple of reorganizations during the plain-text SubmittingPatches era. Fix it by using `the_canonical_patch_format`. [1]: 2ae19aca ("Documentation: Add "how to write a good patch summary" to SubmittingPatches") Signed-off-by: NAkira Yokosawa <akiyks@gmail.com> Fixes: 5903019b ("Documentation/SubmittingPatches: convert it to ReST markup") Fixes: 9b2c7677 ("Documentation/SubmittingPatches: enrich the Sphinx output") Cc: Jonathan Corbet <corbet@lwn.net> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: stable@vger.kernel.org # v4.9+ Link: https://lore.kernel.org/r/64e105a5-50be-23f2-6cae-903a2ea98e18@gmail.comSigned-off-by: NJonathan Corbet <corbet@lwn.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Xiu Jianfeng 提交于
stable inclusion from stable-v5.10.120 commit ebbbffae71e2e0f322bf9e3fadb62d2bee0c33b3 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ebbbffae71e2e0f322bf9e3fadb62d2bee0c33b3 -------------------------------- commit d0dc1a71 upstream. Currently it returns zero when CRQ response timed out, it should return an error code instead. Fixes: d8d74ea3 ("tpm: ibmvtpm: Wait for buffer to be set before proceeding") Signed-off-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NStefan Berger <stefanb@linux.ibm.com> Acked-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Stefan Mahnke-Hartmann 提交于
stable inclusion from stable-v5.10.120 commit 5933a191ac3d6724833d87bd99bda1d1904cb800 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5933a191ac3d6724833d87bd99bda1d1904cb800 -------------------------------- commit e57b2523 upstream. Under certain conditions uninitialized memory will be accessed. As described by TCG Trusted Platform Module Library Specification, rev. 1.59 (Part 3: Commands), if a TPM2_GetCapability is received, requesting a capability, the TPM in field upgrade mode may return a zero length list. Check the property count in tpm2_get_tpm_pt(). Fixes: 2ab32411 ("tpm: migrate tpm2_get_tpm_pt() to use struct tpm_buf") Cc: stable@vger.kernel.org Signed-off-by: NStefan Mahnke-Hartmann <stefan.mahnke-hartmann@infineon.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Tao Jin 提交于
stable inclusion from stable-v5.10.120 commit 0c56e5d0e65531747c437c608d610a2fa8ecd9fe category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0c56e5d0e65531747c437c608d610a2fa8ecd9fe -------------------------------- commit 95cd2cdc upstream. This applies the similar quirks used by previous generation devices such as X1 tablet for X12 tablet, so that the trackpoint and buttons can work. This patch was applied and tested working on 5.17.1 . Cc: stable@vger.kernel.org # 5.8+ given that it relies on 40d5bb87Signed-off-by: NTao Jin <tao-j@outlook.com> Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/CO6PR03MB6241CB276FCDC7F4CEDC34F6E1E29@CO6PR03MB6241.namprd03.prod.outlook.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Marek Maślanka 提交于
stable inclusion from stable-v5.10.120 commit d6822d82c0e8d025fbc157755cab17252ad7092b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d6822d82c0e8d025fbc157755cab17252ad7092b -------------------------------- commit 1d07cef7 upstream. The Google Whiskers touchpad does not work properly with the default multitouch configuration. Instead, use the same configuration as Google Rose. Signed-off-by: NMarek Maslanka <mm@semihalf.com> Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Mariusz Tkaczyk 提交于
stable inclusion from stable-v5.10.120 commit 0f03885059c1f2a5fb690d21578d0cad55a98b1f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0f03885059c1f2a5fb690d21578d0cad55a98b1f -------------------------------- commit 57668f0a upstream. Raid456 module had allowed to achieve failed state. It was fixed by fb73b357 ("raid5: block failing device if raid will be failed"). This fix introduces a bug, now if raid5 fails during IO, it may result with a hung task without completion. Faulty flag on the device is necessary to process all requests and is checked many times, mainly in analyze_stripe(). Allow to set faulty on drive again and set MD_BROKEN if raid is failed. As a result, this level is allowed to achieve failed state again, but communication with userspace (via -EBUSY status) will be preserved. This restores possibility to fail array via #mdadm --set-faulty command and will be fixed by additional verification on mdadm side. Reproduction steps: mdadm -CR imsm -e imsm -n 3 /dev/nvme[0-2]n1 mdadm -CR r5 -e imsm -l5 -n3 /dev/nvme[0-2]n1 --assume-clean mkfs.xfs /dev/md126 -f mount /dev/md126 /mnt/root/ fio --filename=/mnt/root/file --size=5GB --direct=1 --rw=randrw --bs=64k --ioengine=libaio --iodepth=64 --runtime=240 --numjobs=4 --time_based --group_reporting --name=throughput-test-job --eta-newline=1 & echo 1 > /sys/block/nvme2n1/device/device/remove echo 1 > /sys/block/nvme1n1/device/device/remove [ 1475.787779] Call Trace: [ 1475.793111] __schedule+0x2a6/0x700 [ 1475.799460] schedule+0x38/0xa0 [ 1475.805454] raid5_get_active_stripe+0x469/0x5f0 [raid456] [ 1475.813856] ? finish_wait+0x80/0x80 [ 1475.820332] raid5_make_request+0x180/0xb40 [raid456] [ 1475.828281] ? finish_wait+0x80/0x80 [ 1475.834727] ? finish_wait+0x80/0x80 [ 1475.841127] ? finish_wait+0x80/0x80 [ 1475.847480] md_handle_request+0x119/0x190 [ 1475.854390] md_make_request+0x8a/0x190 [ 1475.861041] generic_make_request+0xcf/0x310 [ 1475.868145] submit_bio+0x3c/0x160 [ 1475.874355] iomap_dio_submit_bio.isra.20+0x51/0x60 [ 1475.882070] iomap_dio_bio_actor+0x175/0x390 [ 1475.889149] iomap_apply+0xff/0x310 [ 1475.895447] ? iomap_dio_bio_actor+0x390/0x390 [ 1475.902736] ? iomap_dio_bio_actor+0x390/0x390 [ 1475.909974] iomap_dio_rw+0x2f2/0x490 [ 1475.916415] ? iomap_dio_bio_actor+0x390/0x390 [ 1475.923680] ? atime_needs_update+0x77/0xe0 [ 1475.930674] ? xfs_file_dio_aio_read+0x6b/0xe0 [xfs] [ 1475.938455] xfs_file_dio_aio_read+0x6b/0xe0 [xfs] [ 1475.946084] xfs_file_read_iter+0xba/0xd0 [xfs] [ 1475.953403] aio_read+0xd5/0x180 [ 1475.959395] ? _cond_resched+0x15/0x30 [ 1475.965907] io_submit_one+0x20b/0x3c0 [ 1475.972398] __x64_sys_io_submit+0xa2/0x180 [ 1475.979335] ? do_io_getevents+0x7c/0xc0 [ 1475.986009] do_syscall_64+0x5b/0x1a0 [ 1475.992419] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 1476.000255] RIP: 0033:0x7f11fc27978d [ 1476.006631] Code: Bad RIP value. [ 1476.073251] INFO: task fio:3877 blocked for more than 120 seconds. Cc: stable@vger.kernel.org Fixes: fb73b357 ("raid5: block failing device if raid will be failed") Reviewd-by: NXiao Ni <xni@redhat.com> Signed-off-by: NMariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com> Signed-off-by: NSong Liu <song@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Sarthak Kukreti 提交于
stable inclusion from stable-v5.10.120 commit 8df42bcd364cc3b41105215d841792aea787b133 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8df42bcd364cc3b41105215d841792aea787b133 -------------------------------- commit 4caae584 upstream. The device-mapper framework provides a mechanism to mark targets as immutable (and hence fail table reloads that try to change the target type). Add the DM_TARGET_IMMUTABLE flag to the dm-verity target's feature flags to prevent switching the verity target with a different target type. Fixes: a4ffc152 ("dm: add verity target") Cc: stable@vger.kernel.org Signed-off-by: NSarthak Kukreti <sarthakkukreti@google.com> Reviewed-by: NKees Cook <keescook@chromium.org> Signed-off-by: NMike Snitzer <snitzer@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Conflicts: drivers/md/dm-verity-target.c Reviewed-by: NLuo Meng <luomeng12@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Mikulas Patocka 提交于
stable inclusion from stable-v5.10.120 commit e39b536d70edc5f622187cf787db94287e389c50 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e39b536d70edc5f622187cf787db94287e389c50 -------------------------------- commit bfe2b014 upstream. dm-stats can be used with a very large number of entries (it is only limited by 1/4 of total system memory), so add rescheduling points to the loops that iterate over the entries. Cc: stable@vger.kernel.org Signed-off-by: NMikulas Patocka <mpatocka@redhat.com> Signed-off-by: NMike Snitzer <snitzer@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Mikulas Patocka 提交于
stable inclusion from stable-v5.10.120 commit 4617778417d0a8c59f309b5eea21d943877f3c74 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4617778417d0a8c59f309b5eea21d943877f3c74 -------------------------------- commit 567dd8f3 upstream. The device mapper dm-crypt target is using scnprintf("%02x", cc->key[i]) to report the current key to userspace. However, this is not a constant-time operation and it may leak information about the key via timing, via cache access patterns or via the branch predictor. Change dm-crypt's key printing to use "%c" instead of "%02x". Also introduce hex2asc() that carefully avoids any branching or memory accesses when converting a number in the range 0 ... 15 to an ascii character. Cc: stable@vger.kernel.org Signed-off-by: NMikulas Patocka <mpatocka@redhat.com> Tested-by: NMilan Broz <gmazyland@gmail.com> Signed-off-by: NMike Snitzer <snitzer@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Dan Carpenter 提交于
stable inclusion from stable-v5.10.120 commit bb64957c472adc90eb7dbb45db95019d7a574088 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bb64957c472adc90eb7dbb45db95019d7a574088 -------------------------------- commit d3f2a14b upstream. The "r" variable shadows an earlier "r" that has function scope. It means that we accidentally return success instead of an error code. Smatch has a warning for this: drivers/md/dm-integrity.c:4503 dm_integrity_ctr() warn: missing error code 'r' Fixes: 7eada909 ("dm: add integrity target") Cc: stable@vger.kernel.org Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NMikulas Patocka <mpatocka@redhat.com> Signed-off-by: NMike Snitzer <snitzer@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Jonathan Bakker 提交于
stable inclusion from stable-v5.10.120 commit 8845027e55fc8b977607b4576ca6efd5d8d4566d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8845027e55fc8b977607b4576ca6efd5d8d4566d -------------------------------- commit 3f5e3d3a upstream. Correct the name of the bluetooth interrupt from host-wake to host-wakeup. Fixes: 1c65b618 ("ARM: dts: s5pv210: Correct BCM4329 bluetooth node") Cc: <stable@vger.kernel.org> Signed-off-by: NJonathan Bakker <xc-racer2@live.ca> Link: https://lore.kernel.org/r/CY4PR04MB0567495CFCBDC8D408D44199CB1C9@CY4PR04MB0567.namprd04.prod.outlook.comSigned-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Steven Rostedt 提交于
stable inclusion from stable-v5.10.120 commit 4989bb03342941f2b730b37dfa38bce27b543661 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4989bb03342941f2b730b37dfa38bce27b543661 -------------------------------- commit 72ef9844 upstream. While looking at a crash report on a timer list being corrupted, which usually happens when a timer is freed while still active. This is commonly triggered by code calling del_timer() instead of del_timer_sync() just before freeing. One possible culprit is the hci_qca driver, which does exactly that. Eric mentioned that wake_retrans_timer could be rearmed via the work queue, so also move the destruction of the work queue before del_timer_sync(). Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: stable@vger.kernel.org Fixes: 0ff252c1 ("Bluetooth: hciuart: Add support QCA chipset for UART") Signed-off-by: NSteven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Sultan Alsawaf 提交于
stable inclusion from stable-v5.10.120 commit fae05b2314b147a78fbed1dc4c645d9a66313758 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fae05b2314b147a78fbed1dc4c645d9a66313758 -------------------------------- commit 2505a981 upstream. The asynchronous zspage free worker tries to lock a zspage's entire page list without defending against page migration. Since pages which haven't yet been locked can concurrently migrate off the zspage page list while lock_zspage() churns away, lock_zspage() can suffer from a few different lethal races. It can lock a page which no longer belongs to the zspage and unsafely dereference page_private(), it can unsafely dereference a torn pointer to the next page (since there's a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage's pages (since a single page migration will reconstruct the entire page list, and create_page_chain() unconditionally zeroes out each list pointer in the process). Fix the races by using migrate_read_lock() in lock_zspage() to synchronize with page migration. Link: https://lkml.kernel.org/r/20220509024703.243847-1-sultan@kerneltoast.com Fixes: 77ff4657 ("zsmalloc: zs_page_migrate: skip unnecessary loops but not return -EBUSY if zspage is not inuse") Signed-off-by: NSultan Alsawaf <sultan@kerneltoast.com> Acked-by: NMinchan Kim <minchan@kernel.org> Cc: Nitin Gupta <ngupta@vflare.org> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Vitaly Chikunov 提交于
stable inclusion from stable-v5.10.120 commit 6a1cc25494056e6b8dff243f8b3d9c57259535f6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6a1cc25494056e6b8dff243f8b3d9c57259535f6 -------------------------------- commit 7cc7ab73 upstream. Correctly compare values that shall be greater-or-equal and not just greater. Fixes: 0d7a7864 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm") Cc: <stable@vger.kernel.org> Signed-off-by: NVitaly Chikunov <vt@altlinux.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Fabio Estevam 提交于
stable inclusion from stable-v5.10.120 commit c013f7d1cd92d945398c63a7d6a8b0dd99c23679 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c013f7d1cd92d945398c63a7d6a8b0dd99c23679 -------------------------------- commit 4ee4cdad upstream. Since commit 358ba762 ("crypto: caam - enable prediction resistance in HRWNG") the following CAAM errors can be seen on i.MX6SX: caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error hwrng: no data available This error is due to an incorrect entropy delay for i.MX6SX. Fix it by increasing the minimum entropy delay for i.MX6SX as done in U-Boot: https://patchwork.ozlabs.org/project/uboot/patch/20220415111049.2565744-1-gaurav.jain@nxp.com/ As explained in the U-Boot patch: "RNG self tests are run to determine the correct entropy delay. Such tests are executed with different voltages and temperatures to identify the worst case value for the entropy delay. For i.MX6SX, it was determined that after adding a margin value of 1000 the minimum entropy delay should be at least 12000." Cc: <stable@vger.kernel.org> Fixes: 358ba762 ("crypto: caam - enable prediction resistance in HRWNG") Signed-off-by: NFabio Estevam <festevam@denx.de> Reviewed-by: NHoria Geantă <horia.geanta@nxp.com> Reviewed-by: NVabhav Sharma <vabhav.sharma@nxp.com> Reviewed-by: NGaurav Jain <gaurav.jain@nxp.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Paolo Bonzini 提交于
stable inclusion from stable-v5.10.120 commit a2a3fa5b616a1b4caaf1c352051e169471296d4b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a2a3fa5b616a1b4caaf1c352051e169471296d4b -------------------------------- commit baec4f5a upstream. Commit ddd7ed842627 ("x86/kvm: Alloc dummy async #PF token outside of raw spinlock") leads to the following Smatch static checker warning: arch/x86/kernel/kvm.c:212 kvm_async_pf_task_wake() warn: sleeping in atomic context arch/x86/kernel/kvm.c 202 raw_spin_lock(&b->lock); 203 n = _find_apf_task(b, token); 204 if (!n) { 205 /* 206 * Async #PF not yet handled, add a dummy entry for the token. 207 * Allocating the token must be down outside of the raw lock 208 * as the allocator is preemptible on PREEMPT_RT kernels. 209 */ 210 if (!dummy) { 211 raw_spin_unlock(&b->lock); --> 212 dummy = kzalloc(sizeof(*dummy), GFP_KERNEL); ^^^^^^^^^^ Smatch thinks the caller has preempt disabled. The `smdb.py preempt kvm_async_pf_task_wake` output call tree is: sysvec_kvm_asyncpf_interrupt() <- disables preempt -> __sysvec_kvm_asyncpf_interrupt() -> kvm_async_pf_task_wake() The caller is this: arch/x86/kernel/kvm.c 290 DEFINE_IDTENTRY_SYSVEC(sysvec_kvm_asyncpf_interrupt) 291 { 292 struct pt_regs *old_regs = set_irq_regs(regs); 293 u32 token; 294 295 ack_APIC_irq(); 296 297 inc_irq_stat(irq_hv_callback_count); 298 299 if (__this_cpu_read(apf_reason.enabled)) { 300 token = __this_cpu_read(apf_reason.token); 301 kvm_async_pf_task_wake(token); 302 __this_cpu_write(apf_reason.token, 0); 303 wrmsrl(MSR_KVM_ASYNC_PF_ACK, 1); 304 } 305 306 set_irq_regs(old_regs); 307 } The DEFINE_IDTENTRY_SYSVEC() is a wrapper that calls this function from the call_on_irqstack_cond(). It's inside the call_on_irqstack_cond() where preempt is disabled (unless it's already disabled). The irq_enter/exit_rcu() functions disable/enable preempt. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Sean Christopherson 提交于
stable inclusion from stable-v5.10.120 commit 4a9f3a9c28a6966c699b4264b6a3c5aaed21ea3e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4a9f3a9c28a6966c699b4264b6a3c5aaed21ea3e -------------------------------- commit 0547758a upstream. Drop the raw spinlock in kvm_async_pf_task_wake() before allocating the the dummy async #PF token, the allocator is preemptible on PREEMPT_RT kernels and must not be called from truly atomic contexts. Opportunistically document why it's ok to loop on allocation failure, i.e. why the function won't get stuck in an infinite loop. Reported-by: NYajun Deng <yajun.deng@linux.dev> Cc: stable@vger.kernel.org Signed-off-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Xiaomeng Tong 提交于
stable inclusion from stable-v5.10.120 commit 4c4a11c74adac284534f3db927c726bd419bbacb category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4c4a11c74adac284534f3db927c726bd419bbacb -------------------------------- commit 300981ab upstream. The bug is here: if (!p) return ret; The list iterator value 'p' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found. To fix the bug, Use a new value 'iter' as the list iterator, while use the old value 'p' as a dedicated variable to point to the found element. Fixes: dfaa973a ("KVM: PPC: Book3S HV: In H_SVM_INIT_DONE, migrate remaining normal-GFNs to secure-GFNs") Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: NXiaomeng Tong <xiam0nd.tong@gmail.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220414062103.8153-1-xiam0nd.tong@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Florian Westphal 提交于
stable inclusion from stable-v5.10.120 commit 91a36ec160ec1a0c8f5352b772dffcbb0b6023e3 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=91a36ec160ec1a0c8f5352b772dffcbb0b6023e3 -------------------------------- commit 56b14ece upstream. In case the conntrack is clashing, insertion can free skb->_nfct and set skb->_nfct to the already-confirmed entry. This wasn't found before because the conntrack entry and the extension space used to free'd after an rcu grace period, plus the race needs events enabled to trigger. Reported-by: <syzbot+793a590957d9c1b96620@syzkaller.appspotmail.com> Fixes: 71d8c47f ("netfilter: conntrack: introduce clash resolution on insertion race") Fixes: 2ad9d774 ("netfilter: conntrack: free extension area immediately") Signed-off-by: NFlorian Westphal <fw@strlen.de> Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Nicolai Stange 提交于
stable inclusion from stable-v5.10.120 commit 44f1ce55308d914e911184d3df30a1a6d78253e7 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=44f1ce55308d914e911184d3df30a1a6d78253e7 -------------------------------- commit 074bcd40 upstream. get_random_bytes() usually hasn't full entropy available by the time DRBG instances are first getting seeded from it during boot. Thus, the DRBG implementation registers random_ready_callbacks which would in turn schedule some work for reseeding the DRBGs once get_random_bytes() has sufficient entropy available. For reference, the relevant history around handling DRBG (re)seeding in the context of a not yet fully seeded get_random_bytes() is: commit 16b369a9 ("random: Blocking API for accessing nonblocking_pool") commit 4c787990 ("crypto: drbg - add async seeding operation") commit 205a525c ("random: Add callback API for random pool readiness") commit 57225e67 ("crypto: drbg - Use callback API for random readiness") commit c2719503 ("random: Remove kernel blocking API") However, some time later, the initialization state of get_random_bytes() has been made queryable via rng_is_initialized() introduced with commit 9a47249d ("random: Make crng state queryable"). This primitive now allows for streamlining the DRBG reseeding from get_random_bytes() by replacing that aforementioned asynchronous work scheduling from random_ready_callbacks with some simpler, synchronous code in drbg_generate() next to the related logic already present therein. Apart from improving overall code readability, this change will also enable DRBG users to rely on wait_for_random_bytes() for ensuring that the initial seeding has completed, if desired. The previous patches already laid the grounds by making drbg_seed() to record at each DRBG instance whether it was being seeded at a time when rng_is_initialized() still had been false as indicated by ->seeded == DRBG_SEED_STATE_PARTIAL. All that remains to be done now is to make drbg_generate() check for this condition, determine whether rng_is_initialized() has flipped to true in the meanwhile and invoke a reseed from get_random_bytes() if so. Make this move: - rename the former drbg_async_seed() work handler, i.e. the one in charge of reseeding a DRBG instance from get_random_bytes(), to "drbg_seed_from_random()", - change its signature as appropriate, i.e. make it take a struct drbg_state rather than a work_struct and change its return type from "void" to "int" in order to allow for passing error information from e.g. its __drbg_seed() invocation onwards to callers, - make drbg_generate() invoke this drbg_seed_from_random() once it encounters a DRBG instance with ->seeded == DRBG_SEED_STATE_PARTIAL by the time rng_is_initialized() has flipped to true and - prune everything related to the former, random_ready_callback based mechanism. As drbg_seed_from_random() is now getting invoked from drbg_generate() with the ->drbg_mutex being held, it must not attempt to recursively grab it once again. Remove the corresponding mutex operations from what is now drbg_seed_from_random(). Furthermore, as drbg_seed_from_random() can now report errors directly to its caller, there's no need for it to temporarily switch the DRBG's ->seeded state to DRBG_SEED_STATE_UNSEEDED so that a failure of the subsequently invoked __drbg_seed() will get signaled to drbg_generate(). Don't do it then. Signed-off-by: NNicolai Stange <nstange@suse.de> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> [Jason: for stable, undid the modifications for the backport of 5acd3548.] Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Nicolai Stange 提交于
stable inclusion from stable-v5.10.120 commit e744e34a3c35644b5af2b45053fbd178a15bf73f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e744e34a3c35644b5af2b45053fbd178a15bf73f -------------------------------- commit 262d83a4 upstream. Since commit 42ea507f ("crypto: drbg - reseed often if seedsource is degraded"), the maximum seed lifetime represented by ->reseed_threshold gets temporarily lowered if the get_random_bytes() source cannot provide sufficient entropy yet, as is common during boot, and restored back to the original value again once that has changed. More specifically, if the add_random_ready_callback() invoked from drbg_prepare_hrng() in the course of DRBG instantiation does not return -EALREADY, that is, if get_random_bytes() has not been fully initialized at this point yet, drbg_prepare_hrng() will lower ->reseed_threshold to a value of 50. The drbg_async_seed() scheduled from said random_ready_callback will eventually restore the original value. A future patch will replace the random_ready_callback based notification mechanism and thus, there will be no add_random_ready_callback() return value anymore which could get compared to -EALREADY. However, there's __drbg_seed() which gets invoked in the course of both, the DRBG instantiation as well as the eventual reseeding from get_random_bytes() in aforementioned drbg_async_seed(), if any. Moreover, it knows about the get_random_bytes() initialization state by the time the seed data had been obtained from it: the new_seed_state argument introduced with the previous patch would get set to DRBG_SEED_STATE_PARTIAL in case get_random_bytes() had not been fully initialized yet and to DRBG_SEED_STATE_FULL otherwise. Thus, __drbg_seed() provides a convenient alternative for managing that ->reseed_threshold lowering and restoring at a central place. Move all ->reseed_threshold adjustment code from drbg_prepare_hrng() and drbg_async_seed() respectively to __drbg_seed(). Make __drbg_seed() lower the ->reseed_threshold to 50 in case its new_seed_state argument equals DRBG_SEED_STATE_PARTIAL and let it restore the original value otherwise. There is no change in behaviour. Signed-off-by: NNicolai Stange <nstange@suse.de> Reviewed-by: NStephan Müller <smueller@chronox.de> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Nicolai Stange 提交于
stable inclusion from stable-v5.10.120 commit 54700e82a7a75d0f2b9126b7ff8bdd26efad738a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=54700e82a7a75d0f2b9126b7ff8bdd26efad738a -------------------------------- commit 2bcd2544 upstream. Currently, the DRBG implementation schedules asynchronous works from random_ready_callbacks for reseeding the DRBG instances with output from get_random_bytes() once the latter has sufficient entropy available. However, as the get_random_bytes() initialization state can get queried by means of rng_is_initialized() now, there is no real need for this asynchronous reseeding logic anymore and it's better to keep things simple by doing it synchronously when needed instead, i.e. from drbg_generate() once rng_is_initialized() has flipped to true. Of course, for this to work, drbg_generate() would need some means by which it can tell whether or not rng_is_initialized() has flipped to true since the last seeding from get_random_bytes(). Or equivalently, whether or not the last seed from get_random_bytes() has happened when rng_is_initialized() was still evaluating to false. As it currently stands, enum drbg_seed_state allows for the representation of two different DRBG seeding states: DRBG_SEED_STATE_UNSEEDED and DRBG_SEED_STATE_FULL. The former makes drbg_generate() to invoke a full reseeding operation involving both, the rather expensive jitterentropy as well as the get_random_bytes() randomness sources. The DRBG_SEED_STATE_FULL state on the other hand implies that no reseeding at all is required for a !->pr DRBG variant. Introduce the new DRBG_SEED_STATE_PARTIAL state to enum drbg_seed_state for representing the condition that a DRBG was being seeded when rng_is_initialized() had still been false. In particular, this new state implies that - the given DRBG instance has been fully seeded from the jitterentropy source (if enabled) - and drbg_generate() is supposed to reseed from get_random_bytes() *only* once rng_is_initialized() turns to true. Up to now, the __drbg_seed() helper used to set the given DRBG instance's ->seeded state to constant DRBG_SEED_STATE_FULL. Introduce a new argument allowing for the specification of the to be written ->seeded value instead. Make the first of its two callers, drbg_seed(), determine the appropriate value based on rng_is_initialized(). The remaining caller, drbg_async_seed(), is known to get invoked only once rng_is_initialized() is true, hence let it pass constant DRBG_SEED_STATE_FULL for the new argument to __drbg_seed(). There is no change in behaviour, except for that the pr_devel() in drbg_generate() would now report "unseeded" for ->pr DRBG instances which had last been seeded when rng_is_initialized() was still evaluating to false. Signed-off-by: NNicolai Stange <nstange@suse.de> Reviewed-by: NStephan Müller <smueller@chronox.de> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Nicolai Stange 提交于
stable inclusion from stable-v5.10.120 commit b2bef5500e0d2000c40c361720b0788db2abca5e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b2bef5500e0d2000c40c361720b0788db2abca5e -------------------------------- commit ce8ce31b upstream. There are two different randomness sources the DRBGs are getting seeded from, namely the jitterentropy source (if enabled) and get_random_bytes(). At initial DRBG seeding time during boot, the latter might not have collected sufficient entropy for seeding itself yet and thus, the DRBG implementation schedules a reseed work from a random_ready_callback once that has happened. This is particularly important for the !->pr DRBG instances, for which (almost) no further reseeds are getting triggered during their lifetime. Because collecting data from the jitterentropy source is a rather expensive operation, the aforementioned asynchronously scheduled reseed work restricts itself to get_random_bytes() only. That is, it in some sense amends the initial DRBG seed derived from jitterentropy output at full (estimated) entropy with fresh randomness obtained from get_random_bytes() once that has been seeded with sufficient entropy itself. With the advent of rng_is_initialized(), there is no real need for doing the reseed operation from an asynchronously scheduled work anymore and a subsequent patch will make it synchronous by moving it next to related logic already present in drbg_generate(). However, for tracking whether a full reseed including the jitterentropy source is required or a "partial" reseed involving only get_random_bytes() would be sufficient already, the boolean struct drbg_state's ->seeded member must become a tristate value. Prepare for this by introducing the new enum drbg_seed_state and change struct drbg_state's ->seeded member's type from bool to that type. For facilitating review, enum drbg_seed_state is made to only contain two members corresponding to the former ->seeded values of false and true resp. at this point: DRBG_SEED_STATE_UNSEEDED and DRBG_SEED_STATE_FULL. A third one for tracking the intermediate state of "seeded from jitterentropy only" will be introduced with a subsequent patch. There is no change in behaviour at this point. Signed-off-by: NNicolai Stange <nstange@suse.de> Reviewed-by: NStephan Müller <smueller@chronox.de> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Justin M. Forbes 提交于
stable inclusion from stable-v5.10.120 commit 630192aa45233acfe3d17952862ca215f6d31f09 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=630192aa45233acfe3d17952862ca215f6d31f09 -------------------------------- commit e56e1898 upstream. Commit 6048fdcc ("lib/crypto: blake2s: include as built-in") took away a number of prompt texts from other crypto libraries. This makes values flip from built-in to module when oldconfig runs, and causes problems when these crypto libs need to be built in for thingslike BIG_KEYS. Fixes: 6048fdcc ("lib/crypto: blake2s: include as built-in") Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: linux-crypto@vger.kernel.org Signed-off-by: NJustin M. Forbes <jforbes@fedoraproject.org> [Jason: - moved menu into submenu of lib/ instead of root menu - fixed chacha sub-dependencies for CONFIG_CRYPTO] Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Conflicts: lib/crypto/Kconfig Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Tadeusz Struk 提交于
stable inclusion from stable-v5.10.120 commit 82f723b8a5adf497f9e34c702a30ca7298615654 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=82f723b8a5adf497f9e34c702a30ca7298615654 -------------------------------- commit 64ba4b15 upstream. Syzbot reported slab-out-of-bounds read in exfat_clear_bitmap. This was triggered by reproducer calling truncute with size 0, which causes the following trace: BUG: KASAN: slab-out-of-bounds in exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 Read of size 8 at addr ffff888115aa9508 by task syz-executor251/365 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack_lvl+0x1e2/0x24b lib/dump_stack.c:118 print_address_description+0x81/0x3c0 mm/kasan/report.c:233 __kasan_report mm/kasan/report.c:419 [inline] kasan_report+0x1a4/0x1f0 mm/kasan/report.c:436 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309 exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 exfat_free_cluster+0x25a/0x4a0 fs/exfat/fatent.c:181 __exfat_truncate+0x99e/0xe00 fs/exfat/file.c:217 exfat_truncate+0x11b/0x4f0 fs/exfat/file.c:243 exfat_setattr+0xa03/0xd40 fs/exfat/file.c:339 notify_change+0xb76/0xe10 fs/attr.c:336 do_truncate+0x1ea/0x2d0 fs/open.c:65 Move the is_valid_cluster() helper from fatent.c to a common header to make it reusable in other *.c files. And add is_valid_cluster() to validate if cluster number is within valid range in exfat_clear_bitmap() and exfat_set_bitmap(). Link: https://syzkaller.appspot.com/bug?id=50381fc73821ecae743b8cf24b4c9a04776f767c Reported-by: syzbot+a4087e40b9c13aad7892@syzkaller.appspotmail.com Fixes: 1e49a94c ("exfat: add bitmap operations") Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: NTadeusz Struk <tadeusz.struk@linaro.org> Reviewed-by: NSungjong Seo <sj1557.seo@samsung.com> Signed-off-by: NNamjae Jeon <linkinjeon@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Gustavo A. R. Silva 提交于
stable inclusion from stable-v5.10.120 commit 1f0681f3bd5665080bde3c5b9568cc27df765ce0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1f0681f3bd5665080bde3c5b9568cc27df765ce0 -------------------------------- commit 336feb50 upstream. Fix the following -Wstringop-overflow warnings when building with GCC-11: drivers/gpu/drm/i915/intel_pm.c:3106:9: warning: ‘intel_read_wm_latency’ accessing 16 bytes in a region of size 10 [-Wstringop-overflow=] 3106 | intel_read_wm_latency(dev_priv, dev_priv->wm.pri_latency); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/intel_pm.c:3106:9: note: referencing argument 2 of type ‘u16 *’ {aka ‘short unsigned int *’} drivers/gpu/drm/i915/intel_pm.c:2861:13: note: in a call to function ‘intel_read_wm_latency’ 2861 | static void intel_read_wm_latency(struct drm_i915_private *dev_priv, | ^~~~~~~~~~~~~~~~~~~~~ by removing the over-specified array size from the argument declarations. It seems that this code is actually safe because the size of the array depends on the hardware generation, and the function checks for that. Notice that wm can be an array of 5 elements: drivers/gpu/drm/i915/intel_pm.c:3109: intel_read_wm_latency(dev_priv, dev_priv->wm.pri_latency); or an array of 8 elements: drivers/gpu/drm/i915/intel_pm.c:3131: intel_read_wm_latency(dev_priv, dev_priv->wm.skl_latency); and the compiler legitimately complains about that. This helps with the ongoing efforts to globally enable -Wstringop-overflow. Link: https://github.com/KSPP/linux/issues/181Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Darrick J. Wong 提交于
stable inclusion from stable-v5.10.120 commit f20e67b455e425a0d3d03f27bda5fdd32dc2c324 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f20e67b455e425a0d3d03f27bda5fdd32dc2c324 -------------------------------- commit acf104c2 upstream. Detect file block mappings with a blockcount that's either so large that integer overflows occur or are zero, because neither are valid in the filesystem. Worse yet, attempting directory modifications causes the iext code to trip over the bmbt key handling and takes the filesystem down. We can fix most of this by preventing the bad metadata from entering the incore structures in the first place. Found by setting blockcount=0 in a directory data fork mapping and watching the fireworks. Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NAmir Goldstein <amir73il@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Alex Elder 提交于
stable inclusion from stable-v5.10.120 commit ffc8d613876f0225ac3cfe047fd0ab31623825cf category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ffc8d613876f0225ac3cfe047fd0ab31623825cf -------------------------------- commit c5794097 upstream. The aggregation byte limit for an endpoint is currently computed based on the endpoint's receive buffer size. However, some bytes at the front of each receive buffer are reserved on the assumption that--as with SKBs--it might be useful to insert data (such as headers) before what lands in the buffer. The aggregation byte limit currently doesn't take into account that reserved space, and as a result, aggregation could require space past that which is available in the buffer. Fix this by reducing the size used to compute the aggregation byte limit by the NET_SKB_PAD offset reserved for each receive buffer. Signed-off-by: NAlex Elder <elder@linaro.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Stephen Brennan 提交于
stable inclusion from stable-v5.10.120 commit 6029f86740c92c182ff29b34b3c40bb5462050a1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6029f86740c92c182ff29b34b3c40bb5462050a1 -------------------------------- commit d1dc8776 upstream. A rare BUG_ON triggered in assoc_array_gc: [3430308.818153] kernel BUG at lib/assoc_array.c:1609! Which corresponded to the statement currently at line 1593 upstream: BUG_ON(assoc_array_ptr_is_meta(p)); Using the data from the core dump, I was able to generate a userspace reproducer[1] and determine the cause of the bug. [1]: https://github.com/brenns10/kernel_stuff/tree/master/assoc_array_gc After running the iterator on the entire branch, an internal tree node looked like the following: NODE (nr_leaves_on_branch: 3) SLOT [0] NODE (2 leaves) SLOT [1] NODE (1 leaf) SLOT [2..f] NODE (empty) In the userspace reproducer, the pr_devel output when compressing this node was: -- compress node 0x5607cc089380 -- free=0, leaves=0 [0] retain node 2/1 [nx 0] [1] fold node 1/1 [nx 0] [2] fold node 0/1 [nx 2] [3] fold node 0/2 [nx 2] [4] fold node 0/3 [nx 2] [5] fold node 0/4 [nx 2] [6] fold node 0/5 [nx 2] [7] fold node 0/6 [nx 2] [8] fold node 0/7 [nx 2] [9] fold node 0/8 [nx 2] [10] fold node 0/9 [nx 2] [11] fold node 0/10 [nx 2] [12] fold node 0/11 [nx 2] [13] fold node 0/12 [nx 2] [14] fold node 0/13 [nx 2] [15] fold node 0/14 [nx 2] after: 3 At slot 0, an internal node with 2 leaves could not be folded into the node, because there was only one available slot (slot 0). Thus, the internal node was retained. At slot 1, the node had one leaf, and was able to be folded in successfully. The remaining nodes had no leaves, and so were removed. By the end of the compression stage, there were 14 free slots, and only 3 leaf nodes. The tree was ascended and then its parent node was compressed. When this node was seen, it could not be folded, due to the internal node it contained. The invariant for compression in this function is: whenever nr_leaves_on_branch < ASSOC_ARRAY_FAN_OUT, the node should contain all leaf nodes. The compression step currently cannot guarantee this, given the corner case shown above. To fix this issue, retry compression whenever we have retained a node, and yet nr_leaves_on_branch < ASSOC_ARRAY_FAN_OUT. This second compression will then allow the node in slot 1 to be folded in, satisfying the invariant. Below is the output of the reproducer once the fix is applied: -- compress node 0x560e9c562380 -- free=0, leaves=0 [0] retain node 2/1 [nx 0] [1] fold node 1/1 [nx 0] [2] fold node 0/1 [nx 2] [3] fold node 0/2 [nx 2] [4] fold node 0/3 [nx 2] [5] fold node 0/4 [nx 2] [6] fold node 0/5 [nx 2] [7] fold node 0/6 [nx 2] [8] fold node 0/7 [nx 2] [9] fold node 0/8 [nx 2] [10] fold node 0/9 [nx 2] [11] fold node 0/10 [nx 2] [12] fold node 0/11 [nx 2] [13] fold node 0/12 [nx 2] [14] fold node 0/13 [nx 2] [15] fold node 0/14 [nx 2] internal nodes remain despite enough space, retrying -- compress node 0x560e9c562380 -- free=14, leaves=1 [0] fold node 2/15 [nx 0] after: 3 Changes Acked-by: NXie XiuQi <xiexiuqi@huawei.com> ======= DH: - Use false instead of 0. - Reorder the inserted lines in a couple of places to put retained before next_slot. ver #2) - Fix typo in pr_devel, correct comparison to "<=" Fixes: 3cb98950 ("Add a generic associative array implementation.") Cc: <stable@vger.kernel.org> Signed-off-by: NStephen Brennan <stephen.s.brennan@oracle.com> Signed-off-by: NDavid Howells <dhowells@redhat.com> cc: Andrew Morton <akpm@linux-foundation.org> cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/20220511225517.407935-1-stephen.s.brennan@oracle.com/ # v1 Link: https://lore.kernel.org/r/20220512215045.489140-1-stephen.s.brennan@oracle.com/ # v2 Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Miri Korenblit 提交于
stable inclusion from stable-v5.10.120 commit b96b4aa65bbc0364ea44807f3a32b8d862008aa6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b96b4aa65bbc0364ea44807f3a32b8d862008aa6 -------------------------------- commit 1b7b3ac8 upstream. We used to set regulatory info before the registration of the device and then the regulatory info didn't get set, because the device isn't registered so there isn't a device to set the regulatory info for. So set the regulatory info after the device registration. Call reg_process_self_managed_hints() once again after the device registration because it does nothing before it. Signed-off-by: NMiri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210618133832.c96eadcffe80.I86799c2c866b5610b4cf91115c21d8ceb525c5aa@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-