Sign in
Sign up
Explore
Enterprise
Education
Search
Help
Terms of use
About Us
Explore
Enterprise
Education
Gitee Premium
Gitee AI
AI teammates
Sign in
Sign up
Fetch the repository succeeded.
description of repo status
Open Source
>
Other
>
Operation System
&&
Watch
Unwatch
Watching
Releases Only
Ignoring
128
Star
73
Fork
331
src-openEuler
/
kernel
Closed
Code
Issues
1197
Pull Requests
35
Wiki
Insights
Pipelines
Service
JavaDoc
PHPDoc
Quality Analysis
Jenkins for Gitee
Tencent CloudBase
Tencent Cloud Serverless
悬镜安全
Aliyun SAE
Codeblitz
SBOM
DevLens
Don’t show this again
Update failed. Please try again later!
Remove this flag
Content Risk Flag
This task is identified by
as the content contains sensitive information such as code security bugs, privacy leaks, etc., so it is only accessible to contributors of this repository.
CVE-2022-48984
Done
#IAYRDP
CVE和安全问题
openeuler-ci-bot
owner
Opened this issue
2024-10-22 04:59
一、漏洞信息 漏洞编号:[CVE-2022-48984](https://nvd.nist.gov/vuln/detail/CVE-2022-48984) 漏洞归属组件:[kernel](https://gitee.com/src-openeuler/kernel) 漏洞归属的版本:4.19.140,4.19.194,4.19.90,5.10.0,6.1.0,6.1.14,6.1.19,6.1.5,6.1.6,6.1.8,6.4.0,6.6.0 CVSS V3.0分值: BaseScore:5.5 Medium Vector:CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H 漏洞简述: In the Linux kernel, the following vulnerability has been resolved:can: slcan: fix freed work crashThe LTP test pty03 is causing a crash in slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 Workqueue: 0x0 (events) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Call Trace: <TASK> worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312)Apparently, the slcan s tx_work is freed while being scheduled. Whileslcan_netdev_close() (netdev side) calls flush_work(&sl->tx_work),slcan_close() (tty side) does not. So when the netdev is never set UP,but the tty is stuffed with bytes and forced to wakeup write, the workis scheduled, but never flushed.So add an additional flush_work() to slcan_close() to be sure the workis flushed under all circumstances.The Fixes commit below moved flush_work() from slcan_close() toslcan_netdev_close(). What was the rationale behind it? Maybe we candrop the one in slcan_netdev_close()?I see the same pattern in can327. So it perhaps needs the very same fix. 漏洞公开时间:2024-10-22 04:15:10 漏洞创建时间:2024-10-22 04:59:31 漏洞详情参考链接: https://nvd.nist.gov/vuln/detail/CVE-2022-48984 <details> <summary>更多参考(点击展开)</summary> | 参考来源 | 参考链接 | 来源链接 | | ------- | -------- | -------- | | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/9e2709d58a14a10eb00d919acd7dec071c33f8c8 | | | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/fb855e9f3b6b42c72af3f1eb0b288998fe0d5ebb | | | suse_bugzilla | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48984 | https://bugzilla.suse.com/show_bug.cgi?id=1231982 | | suse_bugzilla | https://www.cve.org/CVERecord?id=CVE-2022-48984 | https://bugzilla.suse.com/show_bug.cgi?id=1231982 | | suse_bugzilla | https://git.kernel.org/stable/c/9e2709d58a14a10eb00d919acd7dec071c33f8c8 | https://bugzilla.suse.com/show_bug.cgi?id=1231982 | | suse_bugzilla | https://git.kernel.org/stable/c/fb855e9f3b6b42c72af3f1eb0b288998fe0d5ebb | https://bugzilla.suse.com/show_bug.cgi?id=1231982 | | suse_bugzilla | https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2022/CVE-2022-48984.mbox | https://bugzilla.suse.com/show_bug.cgi?id=1231982 | | suse_bugzilla | https://bugzilla.redhat.com/show_bug.cgi?id=2320711 | https://bugzilla.suse.com/show_bug.cgi?id=1231982 | | redhat_bugzilla | https://lore.kernel.org/linux-cve-announce/2024102147-CVE-2022-48984-ea9e@gregkh/T | https://bugzilla.redhat.com/show_bug.cgi?id=2320711 | </details> 漏洞分析指导链接: https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md 漏洞数据来源: openBrain开源漏洞感知系统 漏洞补丁信息: <details> <summary>详情(点击展开)</summary> | 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源 | | ------- | -------- | ------- | -------- | --------- | | | | https://git.kernel.org/stable/c/9e2709d58a14a10eb00d919acd7dec071c33f8c8 | | nvd | | | | https://git.kernel.org/stable/c/fb855e9f3b6b42c72af3f1eb0b288998fe0d5ebb | | nvd | </details> 二、漏洞分析结构反馈 影响性分析说明: In the Linux kernel, the following vulnerability has been resolved:can: slcan: fix freed work crashThe LTP test pty03 is causing a crash in slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 Workqueue: 0x0 (events) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Call Trace: <TASK> worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312)Apparently, the slcan s tx_work is freed while being scheduled. Whileslcan_netdev_close() (netdev side) calls flush_work(&sl->tx_work),slcan_close() (tty side) does not. So when the netdev is never set UP,but the tty is stuffed with bytes and forced to wakeup write, the workis scheduled, but never flushed.So add an additional flush_work() to slcan_close() to be sure the workis flushed under all circumstances.The Fixes commit below moved flush_work() from slcan_close() toslcan_netdev_close(). What was the rationale behind it? Maybe we candrop the one in slcan_netdev_close()?I see the same pattern in can327. So it perhaps needs the very same fix. openEuler评分: 5.5 Vector:CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H 受影响版本排查(受影响/不受影响): 1.openEuler-20.03-LTS-SP4(4.19.90):不受影响 2.openEuler-22.03-LTS-SP1(5.10.0):不受影响 3.openEuler-22.03-LTS-SP3(5.10.0):不受影响 4.openEuler-22.03-LTS-SP4(5.10.0):不受影响 5.master(6.6.0):不受影响 6.openEuler-24.03-LTS(6.6.0):不受影响 7.openEuler-24.03-LTS-Next(6.6.0):不受影响 8.openEuler-24.03-LTS-SP1:不受影响 修复是否涉及abi变化(是/否): 1.openEuler-20.03-LTS-SP4(4.19.90):否 2.openEuler-22.03-LTS-SP1(5.10.0):否 3.openEuler-22.03-LTS-SP3(5.10.0):否 4.master(6.6.0):否 5.openEuler-24.03-LTS(6.6.0):否 6.openEuler-24.03-LTS-Next(6.6.0):否 7.openEuler-22.03-LTS-SP4(5.10.0):否 8.openEuler-24.03-LTS-SP1:否 原因说明: 1.openEuler-20.03-LTS-SP4(4.19.90):不受影响-漏洞代码不存在 2.openEuler-22.03-LTS-SP1(5.10.0):不受影响-漏洞代码不存在 3.openEuler-22.03-LTS-SP3(5.10.0):不受影响-漏洞代码不存在 4.openEuler-22.03-LTS-SP4(5.10.0):不受影响-漏洞代码不存在 5.master(6.6.0):不受影响-漏洞代码不存在 6.openEuler-24.03-LTS(6.6.0):不受影响-漏洞代码不存在 7.openEuler-24.03-LTS-Next(6.6.0):不受影响-漏洞代码不存在 8.openEuler-24.03-LTS-SP1:不受影响-漏洞代码不存在
一、漏洞信息 漏洞编号:[CVE-2022-48984](https://nvd.nist.gov/vuln/detail/CVE-2022-48984) 漏洞归属组件:[kernel](https://gitee.com/src-openeuler/kernel) 漏洞归属的版本:4.19.140,4.19.194,4.19.90,5.10.0,6.1.0,6.1.14,6.1.19,6.1.5,6.1.6,6.1.8,6.4.0,6.6.0 CVSS V3.0分值: BaseScore:5.5 Medium Vector:CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H 漏洞简述: In the Linux kernel, the following vulnerability has been resolved:can: slcan: fix freed work crashThe LTP test pty03 is causing a crash in slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 Workqueue: 0x0 (events) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Call Trace: <TASK> worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312)Apparently, the slcan s tx_work is freed while being scheduled. Whileslcan_netdev_close() (netdev side) calls flush_work(&sl->tx_work),slcan_close() (tty side) does not. So when the netdev is never set UP,but the tty is stuffed with bytes and forced to wakeup write, the workis scheduled, but never flushed.So add an additional flush_work() to slcan_close() to be sure the workis flushed under all circumstances.The Fixes commit below moved flush_work() from slcan_close() toslcan_netdev_close(). What was the rationale behind it? Maybe we candrop the one in slcan_netdev_close()?I see the same pattern in can327. So it perhaps needs the very same fix. 漏洞公开时间:2024-10-22 04:15:10 漏洞创建时间:2024-10-22 04:59:31 漏洞详情参考链接: https://nvd.nist.gov/vuln/detail/CVE-2022-48984 <details> <summary>更多参考(点击展开)</summary> | 参考来源 | 参考链接 | 来源链接 | | ------- | -------- | -------- | | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/9e2709d58a14a10eb00d919acd7dec071c33f8c8 | | | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/fb855e9f3b6b42c72af3f1eb0b288998fe0d5ebb | | | suse_bugzilla | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48984 | https://bugzilla.suse.com/show_bug.cgi?id=1231982 | | suse_bugzilla | https://www.cve.org/CVERecord?id=CVE-2022-48984 | https://bugzilla.suse.com/show_bug.cgi?id=1231982 | | suse_bugzilla | https://git.kernel.org/stable/c/9e2709d58a14a10eb00d919acd7dec071c33f8c8 | https://bugzilla.suse.com/show_bug.cgi?id=1231982 | | suse_bugzilla | https://git.kernel.org/stable/c/fb855e9f3b6b42c72af3f1eb0b288998fe0d5ebb | https://bugzilla.suse.com/show_bug.cgi?id=1231982 | | suse_bugzilla | https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2022/CVE-2022-48984.mbox | https://bugzilla.suse.com/show_bug.cgi?id=1231982 | | suse_bugzilla | https://bugzilla.redhat.com/show_bug.cgi?id=2320711 | https://bugzilla.suse.com/show_bug.cgi?id=1231982 | | redhat_bugzilla | https://lore.kernel.org/linux-cve-announce/2024102147-CVE-2022-48984-ea9e@gregkh/T | https://bugzilla.redhat.com/show_bug.cgi?id=2320711 | </details> 漏洞分析指导链接: https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md 漏洞数据来源: openBrain开源漏洞感知系统 漏洞补丁信息: <details> <summary>详情(点击展开)</summary> | 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源 | | ------- | -------- | ------- | -------- | --------- | | | | https://git.kernel.org/stable/c/9e2709d58a14a10eb00d919acd7dec071c33f8c8 | | nvd | | | | https://git.kernel.org/stable/c/fb855e9f3b6b42c72af3f1eb0b288998fe0d5ebb | | nvd | </details> 二、漏洞分析结构反馈 影响性分析说明: In the Linux kernel, the following vulnerability has been resolved:can: slcan: fix freed work crashThe LTP test pty03 is causing a crash in slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 Workqueue: 0x0 (events) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Call Trace: <TASK> worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312)Apparently, the slcan s tx_work is freed while being scheduled. Whileslcan_netdev_close() (netdev side) calls flush_work(&sl->tx_work),slcan_close() (tty side) does not. So when the netdev is never set UP,but the tty is stuffed with bytes and forced to wakeup write, the workis scheduled, but never flushed.So add an additional flush_work() to slcan_close() to be sure the workis flushed under all circumstances.The Fixes commit below moved flush_work() from slcan_close() toslcan_netdev_close(). What was the rationale behind it? Maybe we candrop the one in slcan_netdev_close()?I see the same pattern in can327. So it perhaps needs the very same fix. openEuler评分: 5.5 Vector:CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H 受影响版本排查(受影响/不受影响): 1.openEuler-20.03-LTS-SP4(4.19.90):不受影响 2.openEuler-22.03-LTS-SP1(5.10.0):不受影响 3.openEuler-22.03-LTS-SP3(5.10.0):不受影响 4.openEuler-22.03-LTS-SP4(5.10.0):不受影响 5.master(6.6.0):不受影响 6.openEuler-24.03-LTS(6.6.0):不受影响 7.openEuler-24.03-LTS-Next(6.6.0):不受影响 8.openEuler-24.03-LTS-SP1:不受影响 修复是否涉及abi变化(是/否): 1.openEuler-20.03-LTS-SP4(4.19.90):否 2.openEuler-22.03-LTS-SP1(5.10.0):否 3.openEuler-22.03-LTS-SP3(5.10.0):否 4.master(6.6.0):否 5.openEuler-24.03-LTS(6.6.0):否 6.openEuler-24.03-LTS-Next(6.6.0):否 7.openEuler-22.03-LTS-SP4(5.10.0):否 8.openEuler-24.03-LTS-SP1:否 原因说明: 1.openEuler-20.03-LTS-SP4(4.19.90):不受影响-漏洞代码不存在 2.openEuler-22.03-LTS-SP1(5.10.0):不受影响-漏洞代码不存在 3.openEuler-22.03-LTS-SP3(5.10.0):不受影响-漏洞代码不存在 4.openEuler-22.03-LTS-SP4(5.10.0):不受影响-漏洞代码不存在 5.master(6.6.0):不受影响-漏洞代码不存在 6.openEuler-24.03-LTS(6.6.0):不受影响-漏洞代码不存在 7.openEuler-24.03-LTS-Next(6.6.0):不受影响-漏洞代码不存在 8.openEuler-24.03-LTS-SP1:不受影响-漏洞代码不存在
Comments (
9
)
Sign in
to comment
Status
Done
Backlog
已挂起
Doing
Done
Declined
Assignees
Not set
Labels
CVE/UNAFFECTED
sig/Kernel
Not set
Projects
Unprojected
Unprojected
Pull Requests
None yet
None yet
Successfully merging a pull request will close this issue.
Branches
No related branch
Branches (
-
)
Tags (
-
)
Planed to start   -   Planed to end
-
Top level
Not Top
Top Level: High
Top Level: Medium
Top Level: Low
Priority
Not specified
Serious
Main
Secondary
Unimportant
Duration
(hours)
参与者(3)
1
https://gitee.com/src-openeuler/kernel.git
git@gitee.com:src-openeuler/kernel.git
src-openeuler
kernel
kernel
Going to Help Center
Search
Git 命令在线学习
如何在 Gitee 导入 GitHub 仓库
Git 仓库基础操作
企业版和社区版功能对比
SSH 公钥设置
如何处理代码冲突
仓库体积过大,如何减小?
如何找回被删除的仓库数据
Gitee 产品配额说明
GitHub仓库快速导入Gitee及同步更新
什么是 Release(发行版)
将 PHP 项目自动发布到 packagist.org
Repository Report
Back to the top
Login prompt
This operation requires login to the code cloud account. Please log in before operating.
Go to login
No account. Register