[PATCH OpenHarmony-5.10 00/18] sync 5.10 cve bugfix 01-24
From: Yu Changchun
From: Greg Kroah-Hartman
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Greg Kroah-Hartman
stable inclusion form stable-v5.10.85 commit 7193ad3e50e596ac2192531c58ba83b9e6d2444b issue: #I4RVJ4 CVE: CVE-2021-39685
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Signed-off-by: Yu Changchun
-------------------------------- Sometimes USB hosts can ask for buffers that are too large from endpoint 0, which should not be allowed. If this happens for OUT requests, stall the endpoint, but for IN requests, trim the request size to the endpoint buffer size.
Co-developed-by: Szymon Heidrich
Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chen Jun Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun
Reviewed-by: Wei Yongjun
From: Greg Kroah-Hartman
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Greg Kroah-Hartman
mainline inclusion form mainline-v5.16-rc6 commit f08adf5add9a071160c68bb2a61d697f39ab0758 issue: #I4RVJ4 CVE: CVE-2021-39685
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
Signed-off-by: Yu Changchun
-------------------------------- Szymon rightly pointed out that the previous check for the endpoint direction in bRequestType was not looking at only the bit involved, but rather the whole value. Normally this is ok, but for some request types, bits other than bit 8 could be set and the check for the endpoint length could not stall correctly.
Fix that up by only checking the single bit.
Fixes: 153a2d7e3350 ("USB: gadget: detect too-big endpoint 0 requests") Cc: Felipe Balbi
Reported-by: Szymon Heidrich Link: https://lore.kernel.org/r/20211214184621.385828-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chen Jun Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun ---
Reviewed-by: Wei Yongjun
From: Linus Torvalds
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Linus Torvalds
stable inclusion from stable-5.10.84 commit 4baba6ba56eb91a735a027f783cc4b9276b48d5b category: bugfix issue: #I4RVJ4 CVE: CVE-2021-4083
Signed-off-by: Yu Changchun
------------------------------------------------- commit 054aa8d439b9185d4f5eb9a90282d1ce74772969 upstream.
Jann Horn points out that there is another possible race wrt Unix domain socket garbage collection, somewhat reminiscent of the one fixed in commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK").
See the extended comment about the garbage collection requirements added to unix_peek_fds() by that commit for details.
The race comes from how we can locklessly look up a file descriptor just as it is in the process of being closed, and with the right artificial timing (Jann added a few strategic 'mdelay(500)' calls to do that), the Unix domain socket garbage collector could see the reference count decrement of the close() happen before fget() took its reference to the file and the file was attached onto a new file descriptor.
This is all (intentionally) correct on the 'struct file *' side, with RCU lookups and lockless reference counting very much part of the design. Getting that reference count out of order isn't a problem per se.
But the garbage collector can get confused by seeing this situation of having seen a file not having any remaining external references and then seeing it being attached to an fd.
In commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK") the fix was to serialize the file descriptor install with the garbage collector by taking and releasing the unix_gc_lock.
That's not really an option here, but since this all happens when we are in the process of looking up a file descriptor, we can instead simply just re-check that the file hasn't been closed in the meantime, and just re-do the lookup if we raced with a concurrent close() of the same file descriptor.
Reported-and-tested-by: Jann Horn
Acked-by: Miklos Szeredi Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Baokun Li Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun --- fs/file.c | 4 ++++ 1 file changed, 4 insertions(+)
Reviewed-by: Wei Yongjun
From: Hangyu Hua
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Hangyu Hua
mainline inclusion from mainline-v5.16-rc6 commit bcd0f93353326954817a4f9fa55ec57fb38acbb0 category: bugfix issue: #I4RVJ4 CVE: CVE-2021-45095
Reference: https://patchwork.kernel.org/project/netdevbpf/patch/20211209082839.33985-1-...
should be : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
Signed-off-by: Yu Changchun
------------------------------------------------------------------- sock_hold(sk) is invoked in pep_sock_accept(), but __sock_put(sk) is not invoked in subsequent failure branches(pep_accept_conn() != 0).
Signed-off-by: Hangyu Hua
Link: https://lore.kernel.org/r/20211209082839.33985-1-hbh25y@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Huang Guobin Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun --- net/phonet/pep.c | 1 + 1 file changed, 1 insertion(+)
Looks good to me
From: Jens Wiklander
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Jens Wiklander
stable inclusion from stable-v5.10.89 commit c05d8f66ec3470e5212c4d08c46d6cb5738d600d issue: #I4RVJ4 CVE: CVE-2021-44733
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Signed-off-by: Yu Changchun
-------------------------------- commit dfd0743f1d9ea76931510ed150334d571fbab49d upstream.
Since the tee subsystem does not keep a strong reference to its idle shared memory buffers, it races with other threads that try to destroy a shared memory through a close of its dma-buf fd or by unmapping the memory.
In tee_shm_get_from_id() when a lookup in teedev->idr has been successful, it is possible that the tee_shm is in the dma-buf teardown path, but that path is blocked by the teedev mutex. Since we don't have an API to tell if the tee_shm is in the dma-buf teardown path or not we must find another way of detecting this condition.
Fix this by doing the reference counting directly on the tee_shm using a new refcount_t refcount field. dma-buf is replaced by using anon_inode_getfd() instead, this separates the life-cycle of the underlying file from the tee_shm. tee_shm_put() is updated to hold the mutex when decreasing the refcount to 0 and then remove the tee_shm from teedev->idr before releasing the mutex. This means that the tee_shm can never be found unless it has a refcount larger than 0.
Fixes: 967c9cca2cc5 ("tee: generic TEE subsystem") Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Lars Persson Reviewed-by: Sumit Garg Reported-by: Patrik Lantz Signed-off-by: Jens Wiklander Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chen Jun Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun --- drivers/tee/tee_shm.c | 171 ++++++++++++++++------------------------ include/linux/tee_drv.h | 4 +- 2 files changed, 68 insertions(+), 107 deletions(-)
Reviewed-by: Wei Yongjun
From: Chao Yu
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Chao Yu
maillist inclusion category: bugfix issue: #I4RVJ4 CVE: CVE-2021-45469
Signed-off-by: Yu Changchun
-------------------------------- As Wenqing Liu reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=215235
- Overview page fault in f2fs_setxattr() when mount and operate on corrupted image
- Reproduce tested on kernel 5.16-rc3, 5.15.X under root
1. unzip tmp7.zip 2. ./single.sh f2fs 7
Sometimes need to run the script several times
- Kernel dump loop0: detected capacity change from 0 to 131072 F2FS-fs (loop0): Found nat_bits in checkpoint F2FS-fs (loop0): Mounted with checkpoint version = 7548c2ee BUG: unable to handle page fault for address: ffffe47bc7123f48 RIP: 0010:kfree+0x66/0x320 Call Trace: __f2fs_setxattr+0x2aa/0xc00 [f2fs] f2fs_setxattr+0xfa/0x480 [f2fs] __f2fs_set_acl+0x19b/0x330 [f2fs] __vfs_removexattr+0x52/0x70 __vfs_removexattr_locked+0xb1/0x140 vfs_removexattr+0x56/0x100 removexattr+0x57/0x80 path_removexattr+0xa3/0xc0 __x64_sys_removexattr+0x17/0x20 do_syscall_64+0x37/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae
The root cause is in __f2fs_setxattr(), we missed to do sanity check on last xattr entry, result in out-of-bound memory access during updating inconsistent xattr data of target inode.
After the fix, it can detect such xattr inconsistency as below:
F2FS-fs (loop11): inode (7) has invalid last xattr entry, entry_size: 60676 F2FS-fs (loop11): inode (8) has corrupted xattr F2FS-fs (loop11): inode (8) has corrupted xattr F2FS-fs (loop11): inode (8) has invalid last xattr entry, entry_size: 47736
Cc: stable@vger.kernel.org Reported-by: Wenqing Liu
Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Guo Xuenan Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun --- fs/f2fs/xattr.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
Reviewed-by: Wei Yongjun
From: Michal Koutný
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Michal Koutný
mainline inclusion from mainline-v5.12-rc1 commit da70862efe0065bada33d67a903270cdbbaf07d9 issue: #I4RVJ4 CVE: CVE-2021-4197
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Signed-off-by: Yu Changchun
-------------------------------- The functions cgroup_threads_write and cgroup_procs_write are almost identical. In order to reduce duplication, factor out the common code in similar fashion we already do for other threadgroup/task functions. No functional changes are intended.
Suggested-by: Hao Lee
Signed-off-by: Michal Koutný Reviewed-by: Daniel Jordan Signed-off-by: Tejun Heo Signed-off-by: Lu Jialin Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun --- kernel/cgroup/cgroup.c | 55 +++++++++++------------------------------- 1 file changed, 14 insertions(+), 41 deletions(-)
Reviewed-by: Wei Yongjun
From: Hui Su
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Hui Su
mainline inclusion from mainline-v5.11-rc2 commit 5a7b5f32c5aa628841502d19a813c633ff6ecbe4 issue: #I4RVJ4 CVE: CVE-2021-4197
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Signed-off-by: Yu Changchun
-------------------------------- we have supplied the inline function: of_cft() in cgroup.h.
So replace the direct use 'of->kn->priv' with inline func of_cft(), which is more readable.
Signed-off-by: Hui Su
Signed-off-by: Tejun Heo Signed-off-by: Lu Jialin Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun --- kernel/cgroup/cgroup.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Wei Yongjun
From: Tejun Heo
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Tejun Heo
mainline inclusion from mainline commit 1756d7994ad85c2479af6ae5a9750b92324685af issue: #I4RVJ4 CVE: CVE-2021-4197
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Signed-off-by: Yu Changchun
-------------------------------- cgroup process migration permission checks are performed at write time as whether a given operation is allowed or not is dependent on the content of the write - the PID. This currently uses current's credentials which is a potential security weakness as it may allow scenarios where a less privileged process tricks a more privileged one into writing into a fd that it created.
This patch makes both cgroup2 and cgroup1 process migration interfaces to use the credentials saved at the time of open (file->f_cred) instead of current's.
Reported-by: "Eric W. Biederman"
Suggested-by: Linus Torvalds Fixes: 187fe84067bd ("cgroup: require write perm on common ancestor when moving processes on the default hierarchy") Reviewed-by: Michal Koutný Signed-off-by: Tejun Heo Conflict: kernel/cgroup/cgroup-v1.c Signed-off-by: Lu Jialin Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun --- kernel/cgroup/cgroup-v1.c | 7 ++++--- kernel/cgroup/cgroup.c | 9 ++++++++- 2 files changed, 12 insertions(+), 4 deletions(-)
Reviewed-by: Wei Yongjun
From: Tejun Heo
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Tejun Heo
mainline inclusion from mainline commit 0d2b5955b36250a9428c832664f2079cbf723bec issue: #I4RVJ4 CVE: CVE-2021-4197
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Signed-off-by: Yu Changchun
-------------------------------- of->priv is currently used by each interface file implementation to store private information. This patch collects the current two private data usages into struct cgroup_file_ctx which is allocated and freed by the common path. This allows generic private data which applies to multiple files, which will be used to in the following patch.
Note that cgroup_procs iterator is now embedded as procs.iter in the new cgroup_file_ctx so that it doesn't need to be allocated and freed separately.
v2: union dropped from cgroup_file_ctx and the procs iterator is embedded in cgroup_file_ctx as suggested by Linus.
v3: Michal pointed out that cgroup1's procs pidlist uses of->priv too. Converted. Didn't change to embedded allocation as cgroup1 pidlists get stored for caching.
Signed-off-by: Tejun Heo
Cc: Linus Torvalds Reviewed-by: Michal Koutný Conflict: kernel/cgroup/cgroup.c Signed-off-by: Lu Jialin Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun --- kernel/cgroup/cgroup-internal.h | 17 +++++++++++ kernel/cgroup/cgroup-v1.c | 26 ++++++++-------- kernel/cgroup/cgroup.c | 53 +++++++++++++++++++++------------ 3 files changed, 65 insertions(+), 31 deletions(-)
Reviewed-by: Wei Yongjun
From: Tejun Heo
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Tejun Heo
mainline inclusion from mainline commit e57457641613fef0d147ede8bd6a3047df588b95 issue: #I4RVJ4 CVE: CVE-2021-4197
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Signed-off-by: Yu Changchun
-------------------------------- cgroup process migration permission checks are performed at write time as whether a given operation is allowed or not is dependent on the content of the write - the PID. This currently uses current's cgroup namespace which is a potential security weakness as it may allow scenarios where a less privileged process tricks a more privileged one into writing into a fd that it created.
This patch makes cgroup remember the cgroup namespace at the time of open and uses it for migration permission checks instad of current's. Note that this only applies to cgroup2 as cgroup1 doesn't have namespace support.
This also fixes a use-after-free bug on cgroupns reported in
https://lore.kernel.org/r/00000000000048c15c05d0083397@google.com
Note that backporting this fix also requires the preceding patch.
Reported-by: "Eric W. Biederman"
Suggested-by: Linus Torvalds Cc: Michal Koutný Cc: Oleg Nesterov Reviewed-by: Michal Koutný Reported-by: syzbot+50f5cf33a284ce738b62@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/00000000000048c15c05d0083397@google.com Fixes: 5136f6365ce3 ("cgroup: implement "nsdelegate" mount option") Signed-off-by: Tejun Heo Signed-off-by: Lu Jialin Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun --- kernel/cgroup/cgroup-internal.h | 2 ++ kernel/cgroup/cgroup.c | 28 +++++++++++++++++++--------- 2 files changed, 21 insertions(+), 9 deletions(-)
Reviewed-by: Wei Yongjun
From: Hangyu Hua
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Hangyu Hua
mainline inclusion from mainline-v5.16-rc6 commit 5f9562ebe710c307adc5f666bf1a2162ee7977c0 issue: #I4RVJ4 CVE: CVE-2021-45480
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
Signed-off-by: Yu Changchun
-------------------------------- __rds_conn_create() did not release conn->c_path when loop_trans != 0 and trans->t_prefer_loopback != 0 and is_outgoing == 0.
Fixes: aced3ce57cd3 ("RDS tcp loopback connection can hang") Signed-off-by: Hangyu Hua
Reviewed-by: Sharath Srinivasan Signed-off-by: David S. Miller Signed-off-by: Baisong Zhong zhongbaisong@huawei.com Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun
Reviewed-by: Wei Yongjun
From: Lin Ma
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Lin Ma
stable inclusion form stable-v5.10.82 commit cb14b196d991c864ed2d1b6e79d68a7ce38e6538 issue: #I4RVJ4 CVE: CVE-2021-4202
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Signed-off-by: Yu Changchun
-------------------------------- [ Upstream commit 86cdf8e38792545161dbe3350a7eced558ba4d15 ]
There is a possible data race as shown below:
thread-A in nci_request() | thread-B in nci_close_device() | mutex_lock(&ndev->req_lock); test_bit(NCI_UP, &ndev->flags); | ... | test_and_clear_bit(NCI_UP, &ndev->flags) mutex_lock(&ndev->req_lock); | |
This race will allow __nci_request() to be awaked while the device is getting removed.
Similar to commit e2cb6b891ad2 ("bluetooth: eliminate the potential race condition when removing the HCI controller"). this patch alters the function sequence in nci_request() to prevent the data races between the nci_close_device().
Signed-off-by: Lin Ma
Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation") Link: https://lore.kernel.org/r/20211115145600.8320-1-linma@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Chen Jun Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun ---
Reviewed-by: Wei Yongjun
From: Lin Ma
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Lin Ma
stable inclusion form stable-v5.10.82 commit 73a0d12114b4bc1a9def79a623264754b9df698e issue: #I4RVJ4 CVE: CVE-2021-4202
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Signed-off-by: Yu Changchun
-------------------------------- [ Upstream commit 3e3b5dfcd16a3e254aab61bd1e8c417dd4503102 ]
There is a potential UAF between the unregistration routine and the NFC netlink operations.
The race that cause that UAF can be shown as below:
(FREE) | (USE) nfcmrvl_nci_unregister_dev | nfc_genl_dev_up nci_close_device | nci_unregister_device | nfc_get_device nfc_unregister_device | nfc_dev_up rfkill_destory | device_del | rfkill_blocked ... | ...
The root cause for this race is concluded below: 1. The rfkill_blocked (USE) in nfc_dev_up is supposed to be placed after the device_is_registered check. 2. Since the netlink operations are possible just after the device_add in nfc_register_device, the nfc_dev_up() can happen anywhere during the rfkill creation process, which leads to data race.
This patch reorder these actions to permit 1. Once device_del is finished, the nfc_dev_up cannot dereference the rfkill object. 2. The rfkill_register need to be placed after the device_add of nfc_dev because the parent device need to be created first. So this patch keeps the order but inject device_lock to prevent the data race.
Signed-off-by: Lin Ma
Fixes: be055b2f89b5 ("NFC: RFKILL support") Reviewed-by: Jakub Kicinski Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20211116152652.19217-1-linma@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Chen Jun Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun --- net/nfc/core.c | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-)
Reviewed-by: Wei Yongjun
From: Bongsu Jeon
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Bongsu Jeon
stable inclusion form stable-v5.10.82 commit b2a60b4a0195ba918ce924ba0616048ce09a3cc5 issue: #I4RVJ4 CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Signed-off-by: Yu Changchun
-------------------------------- [ Upstream commit f011539e723c737b74876ac47345e40270a3c384 ]
If there is a NCI command in work queue after closing the NCI device at nci_unregister_device, The NCI command timer starts at flush_workqueue function and then NCI command timeout handler would be called 5 second after flushing the NCI command work queue and destroying the queue. At that time, the timeout handler would try to use NCI command work queue that is destroyed already. it will causes the problem. To avoid this abnormal situation, change the sequence to prevent the NCI command timeout handler from being called after destroying the NCI command work queue.
Signed-off-by: Bongsu Jeon
Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Chen Jun Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun --- net/nfc/nci/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Wei Yongjun
From: Lin Ma
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Lin Ma
stable inclusion form stable-v5.10.82 commit 34e54703fb0fdbfc0a3cfc065d71e9a8353d3ac9 issue: #I4RVJ4 CVE: CVE-2021-4202
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
Signed-off-by: Yu Changchun
-------------------------------- [ Upstream commit 48b71a9e66c2eab60564b1b1c85f4928ed04e406 ]
There are two sites that calls queue_work() after the destroy_workqueue() and lead to possible UAF.
The first site is nci_send_cmd(), which can happen after the nci_close_device as below
nfcmrvl_nci_unregister_dev | nfc_genl_dev_up nci_close_device | flush_workqueue | del_timer_sync | nci_unregister_device | nfc_get_device destroy_workqueue | nfc_dev_up nfc_unregister_device | nci_dev_up device_del | nci_open_device | __nci_request | nci_send_cmd | queue_work !!!
Another site is nci_cmd_timer, awaked by the nci_cmd_work from the nci_send_cmd.
... | ... nci_unregister_device | queue_work destroy_workqueue | nfc_unregister_device | ... device_del | nci_cmd_work | mod_timer | ... | nci_cmd_timer | queue_work !!!
For the above two UAF, the root cause is that the nfc_dev_up can race between the nci_unregister_device routine. Therefore, this patch introduce NCI_UNREG flag to easily eliminate the possible race. In addition, the mutex_lock in nci_close_device can act as a barrier.
Signed-off-by: Lin Ma
Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation") Reviewed-by: Jakub Kicinski Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20211116152732.19238-1-linma@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Chen Jun Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun --- include/net/nfc/nci_core.h | 1 + net/nfc/nci/core.c | 19 +++++++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-)
Reviewed-by: Wei Yongjun
From: Lin Ma
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: Lin Ma
mainline inclusion from mainline-v5.16-rc1 commit aedddb4e45b34426cfbfa84454b6f203712733c5 category: bugfix issue: #I4RVJ4 CVE: CVE-2021-4202
Signed-off-by: Yu Changchun
---------------------------------- The CAP_NET_ADMIN checks are needed to prevent attackers faking a device under NCIUARTSETDRIVER and exploit privileged commands.
This patch add GENL_ADMIN_PERM flags in genl_ops to fulfill the check. Except for commands like NFC_CMD_GET_DEVICE, NFC_CMD_GET_TARGET, NFC_CMD_LLC_GET_PARAMS, and NFC_CMD_GET_SE, which are mainly information- read operations.
Signed-off-by: Lin Ma
Signed-off-by: David S. Miller Signed-off-by: Yu Changchun --- net/nfc/netlink.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
Reviewed-by: Wei Yongjun
From: "Darrick J. Wong"
在 2022/1/24 9:03, yiyuchangchun@126.com 写道:
From: "Darrick J. Wong"
mainline inclusion from mainline-v5.16-rc5 commit 983d8e60f50806f90534cc5373d0ce867e5aaf79 category: bugfix issue: #I4RVJ4 CVE: CVE-2021-4155
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
Signed-off-by: Yu Changchun
-------------------------------- The old ALLOCSP/FREESP ioctls in XFS can be used to preallocate space at the end of files, just like fallocate and RESVSP. Make the behavior consistent with the other ioctls.
Reported-by: Kirill Tkhai
Signed-off-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Reviewed-by: Eric Sandeen Signed-off-by: Guo Xuenan Reviewed-by: Zhang Yi Reviewed-by: Xiu Jianfeng Signed-off-by: Zheng Zengkai Signed-off-by: Yu Changchun --- fs/xfs/xfs_ioctl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Wei Yongjun
participants (2)
-
weiyongjun (A)
-
yiyuchangchun@126.com