- 31 7月, 2023 4 次提交
-
-
由 Lin Ma 提交于
mainline inclusion from mainline-v6.5-rc1 commit 6709d4b7bc2e079241fdef15d1160581c5261c10 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLJR CVE: CVE-2023-3863 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6709d4b7bc2e079241fdef15d1160581c5261c10 --------------------------- This commit fixes several use-after-free that caused by function nfc_llcp_find_local(). For example, one UAF can happen when below buggy time window occurs. // nfc_genl_llc_get_params | // nfc_unregister_device | dev = nfc_get_device(idx); | device_lock(...) if (!dev) | dev->shutting_down = true; return -ENODEV; | device_unlock(...); | device_lock(...); | // nfc_llcp_unregister_device | nfc_llcp_find_local() nfc_llcp_find_local(...); | | local_cleanup() if (!local) { | rc = -ENODEV; | // nfc_llcp_local_put goto exit; | kref_put(.., local_release) } | | // local_release | list_del(&local->list) // nfc_genl_send_params | kfree() local->dev->idx !!!UAF!!! | | and the crash trace for the one of the discussed UAF like: BUG: KASAN: slab-use-after-free in nfc_genl_llc_get_params+0x72f/0x780 net/nfc/netlink.c:1045 Read of size 8 at addr ffff888105b0e410 by task 20114 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:319 [inline] print_report+0xcc/0x620 mm/kasan/report.c:430 kasan_report+0xb2/0xe0 mm/kasan/report.c:536 nfc_genl_send_params net/nfc/netlink.c:999 [inline] nfc_genl_llc_get_params+0x72f/0x780 net/nfc/netlink.c:1045 genl_family_rcv_msg_doit.isra.0+0x1ee/0x2e0 net/netlink/genetlink.c:968 genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline] genl_rcv_msg+0x503/0x7d0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x161/0x430 net/netlink/af_netlink.c:2548 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0x644/0x900 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x934/0xe70 net/netlink/af_netlink.c:1913 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg+0x1b6/0x200 net/socket.c:747 ____sys_sendmsg+0x6e9/0x890 net/socket.c:2501 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555 __sys_sendmsg+0xf7/0x1d0 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f34640a2389 RSP: 002b:00007f3463415168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f34641c1f80 RCX: 00007f34640a2389 RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000006 RBP: 00007f34640ed493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe38449ecf R14: 00007f3463415300 R15: 0000000000022000 </TASK> Allocated by task 20116: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:374 [inline] __kasan_kmalloc+0x7f/0x90 mm/kasan/common.c:383 kmalloc include/linux/slab.h:580 [inline] kzalloc include/linux/slab.h:720 [inline] nfc_llcp_register_device+0x49/0xa40 net/nfc/llcp_core.c:1567 nfc_register_device+0x61/0x260 net/nfc/core.c:1124 nci_register_device+0x776/0xb20 net/nfc/nci/core.c:1257 virtual_ncidev_open+0x147/0x230 drivers/nfc/virtual_ncidev.c:148 misc_open+0x379/0x4a0 drivers/char/misc.c:165 chrdev_open+0x26c/0x780 fs/char_dev.c:414 do_dentry_open+0x6c4/0x12a0 fs/open.c:920 do_open fs/namei.c:3560 [inline] path_openat+0x24fe/0x37e0 fs/namei.c:3715 do_filp_open+0x1ba/0x410 fs/namei.c:3742 do_sys_openat2+0x171/0x4c0 fs/open.c:1356 do_sys_open fs/open.c:1372 [inline] __do_sys_openat fs/open.c:1388 [inline] __se_sys_openat fs/open.c:1383 [inline] __x64_sys_openat+0x143/0x200 fs/open.c:1383 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc Freed by task 20115: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2e/0x50 mm/kasan/generic.c:521 ____kasan_slab_free mm/kasan/common.c:236 [inline] ____kasan_slab_free mm/kasan/common.c:200 [inline] __kasan_slab_free+0x10a/0x190 mm/kasan/common.c:244 kasan_slab_free include/linux/kasan.h:162 [inline] slab_free_hook mm/slub.c:1781 [inline] slab_free_freelist_hook mm/slub.c:1807 [inline] slab_free mm/slub.c:3787 [inline] __kmem_cache_free+0x7a/0x190 mm/slub.c:3800 local_release net/nfc/llcp_core.c:174 [inline] kref_put include/linux/kref.h:65 [inline] nfc_llcp_local_put net/nfc/llcp_core.c:182 [inline] nfc_llcp_local_put net/nfc/llcp_core.c:177 [inline] nfc_llcp_unregister_device+0x206/0x290 net/nfc/llcp_core.c:1620 nfc_unregister_device+0x160/0x1d0 net/nfc/core.c:1179 virtual_ncidev_close+0x52/0xa0 drivers/nfc/virtual_ncidev.c:163 __fput+0x252/0xa20 fs/file_table.c:321 task_work_run+0x174/0x270 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x108/0x110 kernel/entry/common.c:204 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline] syscall_exit_to_user_mode+0x21/0x50 kernel/entry/common.c:297 do_syscall_64+0x4c/0x90 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x72/0xdc Last potentially related work creation: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 __kasan_record_aux_stack+0x95/0xb0 mm/kasan/generic.c:491 kvfree_call_rcu+0x29/0xa80 kernel/rcu/tree.c:3328 drop_sysctl_table+0x3be/0x4e0 fs/proc/proc_sysctl.c:1735 unregister_sysctl_table.part.0+0x9c/0x190 fs/proc/proc_sysctl.c:1773 unregister_sysctl_table+0x24/0x30 fs/proc/proc_sysctl.c:1753 neigh_sysctl_unregister+0x5f/0x80 net/core/neighbour.c:3895 addrconf_notify+0x140/0x17b0 net/ipv6/addrconf.c:3684 notifier_call_chain+0xbe/0x210 kernel/notifier.c:87 call_netdevice_notifiers_info+0xb5/0x150 net/core/dev.c:1937 call_netdevice_notifiers_extack net/core/dev.c:1975 [inline] call_netdevice_notifiers net/core/dev.c:1989 [inline] dev_change_name+0x3c3/0x870 net/core/dev.c:1211 dev_ifsioc+0x800/0xf70 net/core/dev_ioctl.c:376 dev_ioctl+0x3d9/0xf80 net/core/dev_ioctl.c:542 sock_do_ioctl+0x160/0x260 net/socket.c:1213 sock_ioctl+0x3f9/0x670 net/socket.c:1316 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x19e/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc The buggy address belongs to the object at ffff888105b0e400 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 16 bytes inside of freed 1024-byte region [ffff888105b0e400, ffff888105b0e800) The buggy address belongs to the physical page: head:ffffea000416c200 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x200000000010200(slab|head|node=0|zone=2) raw: 0200000000010200 ffff8881000430c0 ffffea00044c7010 ffffea0004510e10 raw: 0000000000000000 00000000000a000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888105b0e300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888105b0e380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888105b0e400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888105b0e480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888105b0e500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb In summary, this patch solves those use-after-free by 1. Re-implement the nfc_llcp_find_local(). The current version does not grab the reference when getting the local from the linked list. For example, the llcp_sock_bind() gets the reference like below: // llcp_sock_bind() local = nfc_llcp_find_local(dev); // A ..... \ | raceable ..... / llcp_sock->local = nfc_llcp_local_get(local); // B There is an apparent race window that one can drop the reference and free the local object fetched in (A) before (B) gets the reference. 2. Some callers of the nfc_llcp_find_local() do not grab the reference at all. For example, the nfc_genl_llc_{{get/set}_params/sdreq} functions. We add the nfc_llcp_local_put() for them. Moreover, we add the necessary error handling function to put the reference. 3. Add the nfc_llcp_remove_local() helper. The local object is removed from the linked list in local_release() when all reference is gone. This patch removes it when nfc_llcp_unregister_device() is called. Therefore, every caller of nfc_llcp_find_local() will get a reference even when the nfc_llcp_unregister_device() is called. This promises no use-after-free for the local object is ever possible. Fixes: 52feb444 ("NFC: Extend netlink interface for LTO, RW, and MIUX parameters support") Fixes: c7aa1225 ("NFC: Take a reference on the LLCP local pointer when creating a socket") Signed-off-by: NLin Ma <linma@zju.edu.cn> Reviewed-by: NSimon Horman <simon.horman@corigine.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
-
由 Krzysztof Kozlowski 提交于
mainline inclusion from mainline-v5.18-rc1 commit ec10fd15 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLJR CVE: CVE-2023-3863 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ec10fd154d934cc4195da3cbd017a12817b41d51 --------------------------- The llcp_sock_connect() error paths were using a mixed way of central exit (goto) and cleanup Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
-
由 Krzysztof Kozlowski 提交于
mainline inclusion from mainline-v5.18-rc1 commit 13a3585b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLJR CVE: CVE-2023-3863 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13a3585b264bfeba018941a713b8d7fc9b8221a2 --------------------------- Nullify the llcp_sock->dev on llcp_sock_connect() error paths, symmetrically to the code llcp_sock_bind(). The non-NULL value of llcp_sock->dev is used in a few places to check whether the socket is still valid. There was no particular issue observed with missing NULL assignment in connect() error path, however a similar case - in the bind() error path - was triggereable. That one was fixed in commit 4ac06a1e ("nfc: fix NULL ptr dereference in llcp_sock_getname() after failed connect"), so the change here seems logical as well. Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
-
由 Aditya Pakki 提交于
mainline inclusion from mainline-v5.1-rc3 commit d7737d42 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLJR CVE: CVE-2023-3863 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d7737d4257459ca8921ff911c88937be1a11ea9d --------------------------- In case of kmemdup failure while setting the service name the patch returns -ENOMEM upstream for processing. Signed-off-by: NAditya Pakki <pakki001@umn.edu> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Conflicts: net/nfc/llcp_sock.c Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
-
- 29 7月, 2023 11 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @liuyonglong86 This patch set fix wrong head when modify the tx feature when sending packets problem and modify the driver version. Link:https://gitee.com/openeuler/kernel/pulls/1571 Reviewed-by: Zhang Changzhong <zhangchangzhong@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @liuyonglong86 This patch set fix some bugs found on hns3 drivers and modify the driver version. Link:https://gitee.com/openeuler/kernel/pulls/1570 Reviewed-by: Zhang Changzhong <zhangchangzhong@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I7OSIE CVE: NA ---------------------------- Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7OSIE CVE: NA ---------------------------- When modify the tx feature, the hns driver will modify the maybe_stop_tx() and fill_desc() functions, if the modify happens during packet sending, will cause the hardware and software pointers do not match, and the port can not work anymore. This patch deletes the maybe_stop_tx() and fill_desc() functions modification when setting tx feature, and use the skb_is_gro() to determine use tso functions or non-tso functions when packets sending. Fixes: 38f616da ("net:hns: Add support of ethtool TSO set option for Hip06 in HNS") Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7OS1B CVE: NA ---------------------------- Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
-
由 Jian Shen 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7OS1B CVE: NA ---------------------------- Currently, the driver knocks the ring doorbell before updating the ring->last_to_use in tx flow. if the hardware transmiting packet and napi poll scheduling are fast enough, it may get the old ring->last_to_use in drivers' napi poll. In this case, the driver will think the tx is not completed, and return directly without clear the flag __QUEUE_STATE_STACK_XOFF, which may cause tx timeout. Fixes: 62ef41eb ("net: hns3: optimize the tx clean process") Signed-off-by: NJian Shen <shenjian15@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7ORRB CVE: NA ---------------------------- Currently, the HNS3 driver reports the rss hash type of each packet based on the rss hash tuples set. It always reports PKT_HASH_TYPE_L4, without checking the type of current packet. It's incorrect. Fixes it by reporting it base on the packet type. Fixes: 232fc64b ("net: hns3: Add HW RSS hash information to RX skb") Fixes: ea485867 ("net: hns3: handle the BD info on the last BD of the packet") Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7OQCS CVE: NA ---------------------------- In hclgevf_mbx_handler() and hclgevf_get_mbx_resp() functions, there is a typical store-store and load-load scenario between received_resp and additional_info. This patch adds barrier to fix the problem. Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
-
由 Jie Wang 提交于
mainline inclusion from mainline-v5.16-rc6 commit 27cbf64a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7OQ7U CVE: NA ---------------------------- Currently, the hns3_remove function firstly uninstall client instance, and then uninstall acceletion engine device. The netdevice is freed in client instance uninstall process, but acceletion engine device uninstall process still use it to trace runtime information. This causes a use after free problem. So fixes it by check the instance register state to avoid use after free. Fixes: d8355240 ("net: hns3: add trace event support for PF/VF mailbox") Signed-off-by: NJie Wang <wangjie125@huawei.com> Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7OPD3 CVE: NA ---------------------------- The variable reset_fail_cnt has moved into the struct rst_stats, but in hclge_reset_end_it(), still using the old reset_fail_cnt, so when reset fail, the reset_fail_cnt is always 0, and will not call nic_call_event() to notify who cares about this event. This patch use the correct variable rst_stats.reset_fail_cnt to fix the problem. Fixes: bc70c292 ("net: hns3: add some DFX info for reset issue") Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Dong Chenchen <dongchenchen2@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/CJCCOKFF4BG2FD7U62KB6TCKIJBCPBKK/ https://gitee.com/src-openeuler/kernel/issues/I7N3N3 Link:https://gitee.com/openeuler/kernel/pulls/1556 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
- 28 7月, 2023 2 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Lu Wei <luwei32@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/6L365ADXKYRWFSYG3HPROXFVPSGHUTTY/ https://gitee.com/src-openeuler/kernel/issues/I7N3N2 Link:https://gitee.com/openeuler/kernel/pulls/1568 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
由 Lee Jones 提交于
mainline inclusion from mainline-v6.4-rc7 commit 04c55383 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7N3N2 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=04c55383fa5689357bcdd2c8036725a55ed632bc -------------------------------- In the event of a failure in tcf_change_indev(), u32_set_parms() will immediately return without decrementing the recently incremented reference counter. If this happens enough times, the counter will rollover and the reference freed, leading to a double free which can be used to do 'bad things'. In order to prevent this, move the point of possible failure above the point where the reference counter is incremented. Also save any meaningful return values to be applied to the return data at the appropriate point in time. This issue was caught with KASAN. Fixes: 705c7091 ("net: sched: cls_u32: no need to call tcf_exts_change for newly allocated struct") Suggested-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NLee Jones <lee@kernel.org> Reviewed-by: NEric Dumazet <edumazet@google.com> Acked-by: NJamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> conflict: net/sched/cls_u32.c Signed-off-by: NLu Wei <luwei32@huawei.com>
-
- 27 7月, 2023 3 次提交
-
-
由 M A Ramdhan 提交于
mainline inclusion from mainline-v6.4 commit 0323bce598eea038714f941ce2b22541c46d488f category: bugfix bugzilla: 189032, https://gitee.com/src-openeuler/kernel/issues/I7N3N3 CVE: CVE-2023-3776 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0323bce598eea038714f941ce2b22541c46d488f --------------------------- In the event of a failure in tcf_change_indev(), fw_set_parms() will immediately return an error after incrementing or decrementing reference counter in tcf_bind_filter(). If attacker can control reference counter to zero and make reference freed, leading to use after free. In order to prevent this, move the point of possible failure above the point where the TC_FW_CLASSID is handled. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by: NM A Ramdhan <ramdhan@starlabs.sg> Signed-off-by: NM A Ramdhan <ramdhan@starlabs.sg> Acked-by: NJamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: NPedro Tammela <pctammela@mojatatu.com> Message-ID: <20230705161530.52003-1-ramdhan@starlabs.sg> Signed-off-by: NJakub Kicinski <kuba@kernel.org> Conflict: net/sched/cls_fw.c Signed-off-by: Ndongchenchen <dongchenchen2@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Longlong Xia <xialonglong1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/TUVVFQUDMHOOCKGRZ5V2L6BODB3T276K/ https://gitee.com/src-openeuler/kernel/issues/I7L0Z9 Link:https://gitee.com/openeuler/kernel/pulls/1549 Reviewed-by: Liu YongQiang <liuyongqiang13@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
由 Carlos Llamas 提交于
stable inclusion from stable-v5.10.182 commit 2218752325a98861dfb10f59a9b0270d6d4abe21 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7L0Z9 CVE: CVE-2023-21255 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2218752325a98861dfb10f59a9b0270d6d4abe21 -------------------------------- commit bdc1c5fa upstream. In binder_transaction_buffer_release() the 'failed_at' offset indicates the number of objects to clean up. However, this function was changed by commit 44d8047f ("binder: use standard functions to allocate fds"), to release all the objects in the buffer when 'failed_at' is zero. This introduced an issue when a transaction buffer is released without any objects having been processed so far. In this case, 'failed_at' is indeed zero yet it is misinterpreted as releasing the entire buffer. This leads to use-after-free errors where nodes are incorrectly freed and subsequently accessed. Such is the case in the following KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in binder_thread_read+0xc40/0x1f30 Read of size 8 at addr ffff4faf037cfc58 by task poc/474 CPU: 6 PID: 474 Comm: poc Not tainted 6.3.0-12570-g7df047b3 #5 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5b8 kasan_report+0xb8/0xfc __asan_load8+0x9c/0xb8 binder_thread_read+0xc40/0x1f30 binder_ioctl+0xd9c/0x1768 __arm64_sys_ioctl+0xd4/0x118 invoke_syscall+0x60/0x188 [...] Allocated by task 474: kasan_save_stack+0x3c/0x64 kasan_set_track+0x2c/0x40 kasan_save_alloc_info+0x24/0x34 __kasan_kmalloc+0xb8/0xbc kmalloc_trace+0x48/0x5c binder_new_node+0x3c/0x3a4 binder_transaction+0x2b58/0x36f0 binder_thread_write+0x8e0/0x1b78 binder_ioctl+0x14a0/0x1768 __arm64_sys_ioctl+0xd4/0x118 invoke_syscall+0x60/0x188 [...] Freed by task 475: kasan_save_stack+0x3c/0x64 kasan_set_track+0x2c/0x40 kasan_save_free_info+0x38/0x5c __kasan_slab_free+0xe8/0x154 __kmem_cache_free+0x128/0x2bc kfree+0x58/0x70 binder_dec_node_tmpref+0x178/0x1fc binder_transaction_buffer_release+0x430/0x628 binder_transaction+0x1954/0x36f0 binder_thread_write+0x8e0/0x1b78 binder_ioctl+0x14a0/0x1768 __arm64_sys_ioctl+0xd4/0x118 invoke_syscall+0x60/0x188 [...] ================================================================== In order to avoid these issues, let's always calculate the intended 'failed_at' offset beforehand. This is renamed and wrapped in a helper function to make it clear and convenient. Fixes: 32e9f56a ("binder: don't detect sender/target during buffer cleanup") Reported-by: NZi Fan Tan <zifantan@google.com> Cc: stable@vger.kernel.org Signed-off-by: NCarlos Llamas <cmllamas@google.com> Acked-by: NTodd Kjos <tkjos@google.com> Link: https://lore.kernel.org/r/20230505203020.4101154-1-cmllamas@google.com [cmllamas: resolve trivial conflict due to missing commit 9864bb48] Signed-off-by: NCarlos Llamas <cmllamas@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NWang Hai <wanghai38@huawei.com> Signed-off-by: NLonglong Xia <xialonglong1@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Ntong tiangen <tongtiangen@huawei.com> Reviewed-by: NNanyong Sun <sunnanyong@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
-
- 25 7月, 2023 4 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @zhangjialin11 https://gitee.com/openeuler/kernel/issues/I7M52S Link:https://gitee.com/openeuler/kernel/pulls/1534 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: Wei Li <liwei391@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
由 Wang ShaoBo 提交于
hulk inclusion category: bugfix bugzilla: 187154, https://gitee.com/openeuler/kernel/issues/I7M52S CVE: NA -------------------------------- Fix mpam memleak issue found by kmemleak: unreferenced object 0xffff204000d1d000 (size 128): comm "cpuhp/24", pid 132, jiffies 4294896121 (age 146328.256s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000dd76fed3>] __kmalloc+0x478/0x664 [<00000000e2fa4b32>] mpam_resctrl_setup_domain+0x290/0x5d0 [<0000000088adc589>] mpam_resctrl_cpu_online+0x14c/0x1d0 [<00000000b223bfaa>] mpam_cpu_online+0x1c8/0x2e4 [<000000004438534a>] cpuhp_invoke_callback+0x1f4/0x11b0 [<0000000049ede841>] cpuhp_thread_fun+0x2b8/0x510 [<000000000d731c73>] smpboot_thread_fn+0x260/0x5a0 [<0000000093c61bad>] kthread+0x27c/0x350 [<00000000379f0572>] ret_from_fork+0x10/0x18 There are two cases causing memleak: 1. When offline all cpus of a domain in mpam_resctrl_cpu_offline(), we only free domain's space but not the space of ctrl_val array. 2. When allocating ctrl_val array failed in mpam_resctrl_setup_domain(), the space of ctrl_val array may not be freed. Fixes: 88371f8b ("arm64/mpam: resctrl: Handle cpuhp and resctrl_dom allocation") Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Nliaoyu <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Zhengchao Shao <shaozhengchao@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/WXOHRQHPIRWXZTKJ26Z6FSX2AX7ALOWX/ https://gitee.com/src-openeuler/kernel/issues/I7N3MX Link:https://gitee.com/openeuler/kernel/pulls/1529 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
由 Pedro Tammela 提交于
mainline inclusion from mainline-v6.5-rc2 commit 3e337087c3b5805fe0b8a46ba622a962880b5d64 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7N3MX CVE: CVE-2023-3611 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e337087c3b5805fe0b8a46ba622a962880b5d64 --------------------------- Lion says: ------- In the QFQ scheduler a similar issue to CVE-2023-31436 persists. Consider the following code in net/sched/sch_qfq.c: static int qfq_enqueue(struct sk_buff *skb, struct Qdisc *sch, struct sk_buff **to_free) { unsigned int len = qdisc_pkt_len(skb), gso_segs; // ... if (unlikely(cl->agg->lmax < len)) { pr_debug("qfq: increasing maxpkt from %u to %u for class %u", cl->agg->lmax, len, cl->common.classid); err = qfq_change_agg(sch, cl, cl->agg->class_weight, len); if (err) { cl->qstats.drops++; return qdisc_drop(skb, sch, to_free); } // ... } Similarly to CVE-2023-31436, "lmax" is increased without any bounds checks according to the packet length "len". Usually this would not impose a problem because packet sizes are naturally limited. This is however not the actual packet length, rather the "qdisc_pkt_len(skb)" which might apply size transformations according to "struct qdisc_size_table" as created by "qdisc_get_stab()" in net/sched/sch_api.c if the TCA_STAB option was set when modifying the qdisc. A user may choose virtually any size using such a table. As a result the same issue as in CVE-2023-31436 can occur, allowing heap out-of-bounds read / writes in the kmalloc-8192 cache. ------- We can create the issue with the following commands: tc qdisc add dev $DEV root handle 1: stab mtu 2048 tsize 512 mpu 0 \ overhead 999999999 linklayer ethernet qfq tc class add dev $DEV parent 1: classid 1:1 htb rate 6mbit burst 15k tc filter add dev $DEV parent 1: matchall classid 1:1 ping -I $DEV 1.1.1.2 This is caused by incorrectly assuming that qdisc_pkt_len() returns a length within the QFQ_MIN_LMAX < len < QFQ_MAX_LMAX. Fixes: 462dbc91 ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost") Reported-by: NLion <nnamrec@gmail.com> Reviewed-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: NPedro Tammela <pctammela@mojatatu.com> Reviewed-by: NSimon Horman <simon.horman@corigine.com> Signed-off-by: NPaolo Abeni <pabeni@redhat.com> Conflicts: net/sched/sch_qfq.c Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>
-
- 24 7月, 2023 2 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @leoliu-oc There are some issues that need to be resolved for Zhaoxin Platform. So remove Zhaoxin uncore code first. ### Issue https://gitee.com/openeuler/kernel/issues/I7LXCE ### Test NA ### Known Issue NA ### Default config change NA Link:https://gitee.com/openeuler/kernel/pulls/1474 Reviewed-by: Zhang Changzhong <zhangchangzhong@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Cai Xinchen <caixinchen1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/CDXL6ZE3KXTCFMM7YK2X5W3WEV3HTB7G/ https://gitee.com/src-openeuler/kernel/issues/I635JD Link:https://gitee.com/openeuler/kernel/pulls/1498 Reviewed-by: Liu YongQiang <liuyongqiang13@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
- 20 7月, 2023 4 次提交
-
-
由 Hyunwoo Kim 提交于
stable inclusion from stable-v4.19.285 commit 7bb9c6e05efcecb15b0354d574efbc36ca321d75 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I635JD CVE: CVE-2022-45886 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7bb9c6e05efcecb15b0354d574efbc36ca321d75 -------------------------------- [ Upstream commit 4172385b ] A race condition may occur between the .disconnect function, which is called when the device is disconnected, and the dvb_device_open() function, which is called when the device node is open()ed. This results in several types of UAFs. The root cause of this is that you use the dvb_device_open() function, which does not implement a conditional statement that checks 'dvbnet->exit'. So, add 'remove_mutex` to protect 'dvbnet->exit' and use locked_dvb_net_open() function to check 'dvbnet->exit'. [mchehab: fix a checkpatch warning] Link: https://lore.kernel.org/linux-media/20221117045925.14297-3-imv4bel@gmail.comSigned-off-by: NHyunwoo Kim <imv4bel@gmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NCai Xinchen <caixinchen1@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @LiuYongQiang0816 two patches from Zheng Yejian Link:https://gitee.com/openeuler/kernel/pulls/1444 Reviewed-by: Xu Kuohai <xukuohai@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Ziyang Xuan <william.xuanziyang@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/A46YSUGPFWTYNDQDDIBLVTYQP7CWKM7I/ https://gitee.com/src-openeuler/kernel/issues/I7ISR1 Link:https://gitee.com/openeuler/kernel/pulls/1469 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Ziyang Xuan <william.xuanziyang@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/DIK47VH6DI376MCBPUDGF7OCT76C4BMQ/ https://gitee.com/openeuler/kernel/issues/I7M991 Link:https://gitee.com/openeuler/kernel/pulls/1472 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
- 19 7月, 2023 3 次提交
-
-
由 leoliu-oc 提交于
zhaoxin inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7LXCE CVE: NA -------------------------------------------- There are some issues that need to be resolved for Zhaoxin Platform. So remove Zhaoxin uncore code first. Signed-off-by: Nleoliu-oc <leoliu-oc@zhaoxin.com>
-
由 Ziyang Xuan 提交于
mainline inclusion from mainline-v6.5-rc2 commit 06a0716949c22e2aefb648526580671197151acc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7M991 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=06a0716949c22e2aefb648526580671197151acc --------------------------- Now in addrconf_mod_rs_timer(), reference idev depends on whether rs_timer is not pending. Then modify rs_timer timeout. There is a time gap in [1], during which if the pending rs_timer becomes not pending. It will miss to hold idev, but the rs_timer is activated. Thus rs_timer callback function addrconf_rs_timer() will be executed and put idev later without holding idev. A refcount underflow issue for idev can be caused by this. if (!timer_pending(&idev->rs_timer)) in6_dev_hold(idev); <--------------[1] mod_timer(&idev->rs_timer, jiffies + when); To fix the issue, hold idev if mod_timer() return 0. Fixes: b7b1bfce ("ipv6: split duplicate address detection and router solicitation timer") Suggested-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com> Reviewed-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
-
mainline inclusion from mainline-v6.5-rc2 commit caf3ef7468f7534771b5c44cd8dbd6f7f87c2cbd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7ISR1 CVE: CVE-2023-35001 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=caf3ef7468f7534771b5c44cd8dbd6f7f87c2cbd --------------------------- When evaluating byteorder expressions with size 2, a union with 32-bit and 16-bit members is used. Since the 16-bit members are aligned to 32-bit, the array accesses will be out-of-bounds. It may lead to a stack-out-of-bounds access like the one below: [ 23.095215] ================================================================== [ 23.095625] BUG: KASAN: stack-out-of-bounds in nft_byteorder_eval+0x13c/0x320 [ 23.096020] Read of size 2 at addr ffffc90000007948 by task ping/115 [ 23.096358] [ 23.096456] CPU: 0 PID: 115 Comm: ping Not tainted 6.4.0+ #413 [ 23.096770] Call Trace: [ 23.096910] <IRQ> [ 23.097030] dump_stack_lvl+0x60/0xc0 [ 23.097218] print_report+0xcf/0x630 [ 23.097388] ? nft_byteorder_eval+0x13c/0x320 [ 23.097577] ? kasan_addr_to_slab+0xd/0xc0 [ 23.097760] ? nft_byteorder_eval+0x13c/0x320 [ 23.097949] kasan_report+0xc9/0x110 [ 23.098106] ? nft_byteorder_eval+0x13c/0x320 [ 23.098298] __asan_load2+0x83/0xd0 [ 23.098453] nft_byteorder_eval+0x13c/0x320 [ 23.098659] nft_do_chain+0x1c8/0xc50 [ 23.098852] ? __pfx_nft_do_chain+0x10/0x10 [ 23.099078] ? __kasan_check_read+0x11/0x20 [ 23.099295] ? __pfx___lock_acquire+0x10/0x10 [ 23.099535] ? __pfx___lock_acquire+0x10/0x10 [ 23.099745] ? __kasan_check_read+0x11/0x20 [ 23.099929] nft_do_chain_ipv4+0xfe/0x140 [ 23.100105] ? __pfx_nft_do_chain_ipv4+0x10/0x10 [ 23.100327] ? lock_release+0x204/0x400 [ 23.100515] ? nf_hook.constprop.0+0x340/0x550 [ 23.100779] nf_hook_slow+0x6c/0x100 [ 23.100977] ? __pfx_nft_do_chain_ipv4+0x10/0x10 [ 23.101223] nf_hook.constprop.0+0x334/0x550 [ 23.101443] ? __pfx_ip_local_deliver_finish+0x10/0x10 [ 23.101677] ? __pfx_nf_hook.constprop.0+0x10/0x10 [ 23.101882] ? __pfx_ip_rcv_finish+0x10/0x10 [ 23.102071] ? __pfx_ip_local_deliver_finish+0x10/0x10 [ 23.102291] ? rcu_read_lock_held+0x4b/0x70 [ 23.102481] ip_local_deliver+0xbb/0x110 [ 23.102665] ? __pfx_ip_rcv+0x10/0x10 [ 23.102839] ip_rcv+0x199/0x2a0 [ 23.102980] ? __pfx_ip_rcv+0x10/0x10 [ 23.103140] __netif_receive_skb_one_core+0x13e/0x150 [ 23.103362] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 23.103647] ? mark_held_locks+0x48/0xa0 [ 23.103819] ? process_backlog+0x36c/0x380 [ 23.103999] __netif_receive_skb+0x23/0xc0 [ 23.104179] process_backlog+0x91/0x380 [ 23.104350] __napi_poll.constprop.0+0x66/0x360 [ 23.104589] ? net_rx_action+0x1cb/0x610 [ 23.104811] net_rx_action+0x33e/0x610 [ 23.105024] ? _raw_spin_unlock+0x23/0x50 [ 23.105257] ? __pfx_net_rx_action+0x10/0x10 [ 23.105485] ? mark_held_locks+0x48/0xa0 [ 23.105741] __do_softirq+0xfa/0x5ab [ 23.105956] ? __dev_queue_xmit+0x765/0x1c00 [ 23.106193] do_softirq.part.0+0x49/0xc0 [ 23.106423] </IRQ> [ 23.106547] <TASK> [ 23.106670] __local_bh_enable_ip+0xf5/0x120 [ 23.106903] __dev_queue_xmit+0x789/0x1c00 [ 23.107131] ? __pfx___dev_queue_xmit+0x10/0x10 [ 23.107381] ? find_held_lock+0x8e/0xb0 [ 23.107585] ? lock_release+0x204/0x400 [ 23.107798] ? neigh_resolve_output+0x185/0x350 [ 23.108049] ? mark_held_locks+0x48/0xa0 [ 23.108265] ? neigh_resolve_output+0x185/0x350 [ 23.108514] neigh_resolve_output+0x246/0x350 [ 23.108753] ? neigh_resolve_output+0x246/0x350 [ 23.109003] ip_finish_output2+0x3c3/0x10b0 [ 23.109250] ? __pfx_ip_finish_output2+0x10/0x10 [ 23.109510] ? __pfx_nf_hook+0x10/0x10 [ 23.109732] __ip_finish_output+0x217/0x390 [ 23.109978] ip_finish_output+0x2f/0x130 [ 23.110207] ip_output+0xc9/0x170 [ 23.110404] ip_push_pending_frames+0x1a0/0x240 [ 23.110652] raw_sendmsg+0x102e/0x19e0 [ 23.110871] ? __pfx_raw_sendmsg+0x10/0x10 [ 23.111093] ? lock_release+0x204/0x400 [ 23.111304] ? __mod_lruvec_page_state+0x148/0x330 [ 23.111567] ? find_held_lock+0x8e/0xb0 [ 23.111777] ? find_held_lock+0x8e/0xb0 [ 23.111993] ? __rcu_read_unlock+0x7c/0x2f0 [ 23.112225] ? aa_sk_perm+0x18a/0x550 [ 23.112431] ? filemap_map_pages+0x4f1/0x900 [ 23.112665] ? __pfx_aa_sk_perm+0x10/0x10 [ 23.112880] ? find_held_lock+0x8e/0xb0 [ 23.113098] inet_sendmsg+0xa0/0xb0 [ 23.113297] ? inet_sendmsg+0xa0/0xb0 [ 23.113500] ? __pfx_inet_sendmsg+0x10/0x10 [ 23.113727] sock_sendmsg+0xf4/0x100 [ 23.113924] ? move_addr_to_kernel.part.0+0x4f/0xa0 [ 23.114190] __sys_sendto+0x1d4/0x290 [ 23.114391] ? __pfx___sys_sendto+0x10/0x10 [ 23.114621] ? __pfx_mark_lock.part.0+0x10/0x10 [ 23.114869] ? lock_release+0x204/0x400 [ 23.115076] ? find_held_lock+0x8e/0xb0 [ 23.115287] ? rcu_is_watching+0x23/0x60 [ 23.115503] ? __rseq_handle_notify_resume+0x6e2/0x860 [ 23.115778] ? __kasan_check_write+0x14/0x30 [ 23.116008] ? blkcg_maybe_throttle_current+0x8d/0x770 [ 23.116285] ? mark_held_locks+0x28/0xa0 [ 23.116503] ? do_syscall_64+0x37/0x90 [ 23.116713] __x64_sys_sendto+0x7f/0xb0 [ 23.116924] do_syscall_64+0x59/0x90 [ 23.117123] ? irqentry_exit_to_user_mode+0x25/0x30 [ 23.117387] ? irqentry_exit+0x77/0xb0 [ 23.117593] ? exc_page_fault+0x92/0x140 [ 23.117806] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 23.118081] RIP: 0033:0x7f744aee2bba [ 23.118282] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 [ 23.119237] RSP: 002b:00007ffd04a7c9f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 23.119644] RAX: ffffffffffffffda RBX: 00007ffd04a7e0a0 RCX: 00007f744aee2bba [ 23.120023] RDX: 0000000000000040 RSI: 000056488e9e6300 RDI: 0000000000000003 [ 23.120413] RBP: 000056488e9e6300 R08: 00007ffd04a80320 R09: 0000000000000010 [ 23.120809] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040 [ 23.121219] R13: 00007ffd04a7dc38 R14: 00007ffd04a7ca00 R15: 00007ffd04a7e0a0 [ 23.121617] </TASK> [ 23.121749] [ 23.121845] The buggy address belongs to the virtual mapping at [ 23.121845] [ffffc90000000000, ffffc90000009000) created by: [ 23.121845] irq_init_percpu_irqstack+0x1cf/0x270 [ 23.122707] [ 23.122803] The buggy address belongs to the physical page: [ 23.123104] page:0000000072ac19f0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x24a09 [ 23.123609] flags: 0xfffffc0001000(reserved|node=0|zone=1|lastcpupid=0x1fffff) [ 23.123998] page_type: 0xffffffff() [ 23.124194] raw: 000fffffc0001000 ffffea0000928248 ffffea0000928248 0000000000000000 [ 23.124610] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 23.125023] page dumped because: kasan: bad access detected [ 23.125326] [ 23.125421] Memory state around the buggy address: [ 23.125682] ffffc90000007800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 23.126072] ffffc90000007880: 00 00 00 00 00 f1 f1 f1 f1 f1 f1 00 00 f2 f2 00 [ 23.126455] >ffffc90000007900: 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00 00 00 [ 23.126840] ^ [ 23.127138] ffffc90000007980: 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 [ 23.127522] ffffc90000007a00: f3 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 [ 23.127906] ================================================================== [ 23.128324] Disabling lock debugging due to kernel taint Using simple s16 pointers for the 16-bit accesses fixes the problem. For the 32-bit accesses, src and dst can be used directly. Fixes: 96518518 ("netfilter: add nftables") Cc: stable@vger.kernel.org Reported-by: Tanguy DUBROCA (@SidewayRE) from @Synacktiv working with ZDI Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com> Reviewed-by: NFlorian Westphal <fw@strlen.de> Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
-
- 18 7月, 2023 3 次提交
-
-
由 Zheng Yejian 提交于
mainline inclusion from mainline-v6.5-rc2 commit 26efd79c4624294e553aeaa3439c646729bad084 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7KYPM CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=26efd79c4624294e553aeaa3439c646729bad084 -------------------------------- As comments in ftrace_process_locs(), there may be NULL pointers in mcount_loc section: > Some architecture linkers will pad between > the different mcount_loc sections of different > object files to satisfy alignments. > Skip any NULL pointers. After commit 20e5227e ("ftrace: allow NULL pointers in mcount_loc"), NULL pointers will be accounted when allocating ftrace pages but skipped before adding into ftrace pages, this may result in some pages not being used. Then after commit 706c81f8 ("ftrace: Remove extra helper functions"), warning may occur at: WARN_ON(pg->next); To fix it, only warn for case that no pointers skipped but pages not used up, then free those unused pages after releasing ftrace_lock. Link: https://lore.kernel.org/linux-trace-kernel/20230712060452.3175675-1-zhengyejian1@huawei.com Cc: stable@vger.kernel.org Fixes: 706c81f8 ("ftrace: Remove extra helper functions") Suggested-by: NSteven Rostedt <rostedt@goodmis.org> Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com> Signed-off-by: NSteven Rostedt (Google) <rostedt@goodmis.org> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Zheng Yejian 提交于
mainline inclusion from mainline-v6.5-rc2 commit 7e42907f3a7b4ce3a2d1757f6d78336984daf8f5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7KXY9 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e42907f3a7b4ce3a2d1757f6d78336984daf8f5 --------------------------- Soft lockup occurs when reading file 'trace_pipe': watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488] [...] RIP: 0010:ring_buffer_empty_cpu+0xed/0x170 RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218 RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901 R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000 [...] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __find_next_entry+0x1a8/0x4b0 ? peek_next_entry+0x250/0x250 ? down_write+0xa5/0x120 ? down_write_killable+0x130/0x130 trace_find_next_entry_inc+0x3b/0x1d0 tracing_read_pipe+0x423/0xae0 ? tracing_splice_read_pipe+0xcb0/0xcb0 vfs_read+0x16b/0x490 ksys_read+0x105/0x210 ? __ia32_sys_pwrite64+0x200/0x200 ? switch_fpu_return+0x108/0x220 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 Through the vmcore, I found it's because in tracing_read_pipe(), ring_buffer_empty_cpu() found some buffer is not empty but then it cannot read anything due to "rb_num_of_entries() == 0" always true, Then it infinitely loop the procedure due to user buffer not been filled, see following code path: tracing_read_pipe() { ... ... waitagain: tracing_wait_pipe() // 1. find non-empty buffer here trace_find_next_entry_inc() // 2. loop here try to find an entry __find_next_entry() ring_buffer_empty_cpu(); // 3. find non-empty buffer peek_next_entry() // 4. but peek always return NULL ring_buffer_peek() rb_buffer_peek() rb_get_reader_page() // 5. because rb_num_of_entries() == 0 always true here // then return NULL // 6. user buffer not been filled so goto 'waitgain' // and eventually leads to an deadloop in kernel!!! } By some analyzing, I found that when resetting ringbuffer, the 'entries' of its pages are not all cleared (see rb_reset_cpu()). Then when reducing the ringbuffer, and if some reduced pages exist dirty 'entries' data, they will be added into 'cpu_buffer->overrun' (see rb_remove_pages()), which cause wrong 'overrun' count and eventually cause the deadloop issue. To fix it, we need to clear every pages in rb_reset_cpu(). Link: https://lore.kernel.org/linux-trace-kernel/20230708225144.3785600-1-zhengyejian1@huawei.com Cc: stable@vger.kernel.org Fixes: a5fb8331 ("ring-buffer: Fix uninitialized read_stamp") Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com> Signed-off-by: NSteven Rostedt (Google) <rostedt@goodmis.org> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @LiuYongQiang0816 3 patches from Lu Wei Link:https://gitee.com/openeuler/kernel/pulls/1435 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
-
- 17 7月, 2023 4 次提交
-
-
由 Pablo Neira Ayuso 提交于
mainline inclusion from mainline-v6.4 commit 3e70489721b6c870252c9082c496703677240f53 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7H68N CVE: CVE-2023-3117 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e70489721b6c870252c9082c496703677240f53 -------------------------------- Otherwise a dangling reference to a rule object that is gone remains in the set binding list. Fixes: 26b5a571 ("netfilter: nf_tables: add NFT_TRANS_PREPARE_ERROR to deal with bound set/chain") Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Pablo Neira Ayuso 提交于
mainline inclusion from mainline-v6.4 commit 26b5a571 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7H68N CVE: CVE-2023-3117 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=26b5a5712eb85e253724e56a54c17f8519bd8e4e -------------------------------- Add a new state to deal with rule expressions deactivation from the newrule error path, otherwise the anonymous set remains in the list in inactive state for the next generation. Mark the set/chain transaction as unbound so the abort path releases this object, set it as inactive in the next generation so it is not reachable anymore from this transaction and reference counter is dropped. Fixes: 1240eb93 ("netfilter: nf_tables: incorrect error path handling with NFT_MSG_NEWRULE") Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> conflict: include/net/netfilter/nf_tables.h net/netfilter/nf_tables_api.c Signed-off-by: NLu Wei <luwei32@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Pablo Neira Ayuso 提交于
mainline inclusion from mainline-v6.4-rc7 commit 1240eb93 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7H68N CVE: CVE-2023-3117 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1240eb93f0616b21c675416516ff3d74798fdc97 -------------------------------- In case of error when adding a new rule that refers to an anonymous set, deactivate expressions via NFT_TRANS_PREPARE state, not NFT_TRANS_RELEASE. Thus, the lookup expression marks anonymous sets as inactive in the next generation to ensure it is not reachable in this transaction anymore and decrement the set refcount as introduced by c1592a89 ("netfilter: nf_tables: deactivate anonymous set from preparation phase"). The abort step takes care of undoing the anonymous set. This is also consistent with rule deletion, where NFT_TRANS_PREPARE is used. Note that this error path is exercised in the preparation step of the commit protocol. This patch replaces nf_tables_rule_release() by the deactivate and destroy calls, this time with NFT_TRANS_PREPARE. Due to this incorrect error handling, it is possible to access a dangling pointer to the anonymous set that remains in the transaction list. [1009.379054] BUG: KASAN: use-after-free in nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379106] Read of size 8 at addr ffff88816c4c8020 by task nft-rule-add/137110 [1009.379116] CPU: 7 PID: 137110 Comm: nft-rule-add Not tainted 6.4.0-rc4+ #256 [1009.379128] Call Trace: [1009.379132] <TASK> [1009.379135] dump_stack_lvl+0x33/0x50 [1009.379146] ? nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379191] print_address_description.constprop.0+0x27/0x300 [1009.379201] kasan_report+0x107/0x120 [1009.379210] ? nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379255] nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379302] nft_lookup_init+0xa5/0x270 [nf_tables] [1009.379350] nf_tables_newrule+0x698/0xe50 [nf_tables] [1009.379397] ? nf_tables_rule_release+0xe0/0xe0 [nf_tables] [1009.379441] ? kasan_unpoison+0x23/0x50 [1009.379450] nfnetlink_rcv_batch+0x97c/0xd90 [nfnetlink] [1009.379470] ? nfnetlink_rcv_msg+0x480/0x480 [nfnetlink] [1009.379485] ? __alloc_skb+0xb8/0x1e0 [1009.379493] ? __alloc_skb+0xb8/0x1e0 [1009.379502] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0 [1009.379509] ? unwind_get_return_address+0x2a/0x40 [1009.379517] ? write_profile+0xc0/0xc0 [1009.379524] ? avc_lookup+0x8f/0xc0 [1009.379532] ? __rcu_read_unlock+0x43/0x60 Fixes: 958bee14 ("netfilter: nf_tables: use new transaction infrastructure to handle sets") Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> conflict: net/netfilter/nf_tables_api.c Signed-off-by: NLu Wei <luwei32@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @zh-hhhhh If you run qemu-img convert -t none when iscsi back-end storage is used (mounted using multipath), an error message is displayed indicating Device or resource busy. The error message is resolved after patch is added bugzilla: https://gitee.com/openeuler/kernel/issues/I7GDLI Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/block_dev.c?h=v5.10.180&id=d44c9780ed40db88626c9354868eab72159c7a7f Link:https://gitee.com/openeuler/kernel/pulls/1400 Reviewed-by: Zhang Changzhong <zhangchangzhong@huawei.com> Reviewed-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
-