PR for completion of LE-2004 by gvrose8192 · Pull Request #8 · ctrliq/kernel-src-tree

gvrose8192 · 2024-11-12T22:26:41Z

This PR will complete LE-2004 and all subsidiary tasks.

Vulnerabilities and CVEs addressed include:

jira VULN-683
cve CVE-2023-6622

jira VULN-827
cve CVE-2024-26642

jira VULN-7047
cve CVE-2024-27397

jira VULN-5238
cve CVE-2024-36005

jira VULN-4905
cve CVE-2024-26925

jira VULN-4905
cve CVE-2024-27020

jira VULN-4961
cve CVE-2024-27019

jira VULN-4985
cve CVE-2024-27065

jira VULN-5126
cve CVE-2024-35899

jira VULN-5134
cve CVE-2024-35900

jira VULN-5118
cve CVE-2024-35897

Builds / install / boots
build.log
[root@lts86-base kernel-build-tmp]# uname -a
Linux lts86-base 4.18.0-debug-branch+ #2 SMP Tue Nov 12 13:01:58 EST 2024 x86_64 x86_64 x86_64 GNU/Linux

Before and after kernel selftest logs:
kernel-selftest-before.log
kernel-selftest-after.log

The kernel selftest was run with lockdep and kmemleak enabled - kmemleak showed no kernel memory leaks and the log shows no new errors - although as usual the lockdep checker showed some lockups in the break testings. Nothing unusual or out of the norm:
kst-ldpon-log.log

The kernel selftest with lockdep and kmemleak on was run with stress: sudo stress --cpu 28 --io 28 --vm 28 --vm-bytes 1G --timeout 3h

There are some notable conflicts resolved in the commits for this PR - due diligence and attention required.

Netfilter tables tests were also run with lockdep and kmemleak:
nftables-test.log

…ent path jira VULN-5238 cve CVE-2024-36005 commit-author Pablo Neira Ayuso <pablo@netfilter.org> commit 8e30abc Check for table dormant flag otherwise netdev release event path tries to unregister an already unregistered hook. [524854.857999] ------------[ cut here ]------------ [524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260 [...] [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365 [524854.858869] Workqueue: netns cleanup_net [524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260 [524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41 [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246 [524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438 [524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34 [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005 [524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00 [524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0 [524854.859000] Call Trace: [524854.859006] <TASK> [524854.859013] ? __warn+0x9f/0x1a0 [524854.859027] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859044] ? report_bug+0x1b1/0x1e0 [524854.859060] ? handle_bug+0x3c/0x70 [524854.859071] ? exc_invalid_op+0x17/0x40 [524854.859083] ? asm_exc_invalid_op+0x1a/0x20 [524854.859100] ? __nf_unregister_net_hook+0x6a/0x260 [524854.859116] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859135] nf_tables_netdev_event+0x337/0x390 [nf_tables] [524854.859304] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables] [524854.859461] ? packet_notifier+0xb3/0x360 [524854.859476] ? _raw_spin_unlock_irqrestore+0x11/0x40 [524854.859489] ? dcbnl_netdevice_event+0x35/0x140 [524854.859507] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables] [524854.859661] notifier_call_chain+0x7d/0x140 [524854.859677] unregister_netdevice_many_notify+0x5e1/0xae0 Fixes: d54725c ("netfilter: nf_tables: support for multiple devices per netdev hook") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 8e30abc) Signed-off-by: Greg Rose <g.v.rose@ciq.com>

PlaidCat · 2024-11-13T21:59:38Z

The commit message here: d9a8f26

jira VULN-4905
cve CVE-2024-27020
commit-author Ziyang Xuan <william.xuanziyang@huawei.com>
commit https://github.com/ctrliq/kernel-src-tree/commit/f969eb84ce482331a991079ab7a5c4dc3b7f89bf

The ticket number is wrong for the CVECVE-2024-27020, it should be VULN-4969

jira VULN-4969 subsystem-sync netfilter:nf_tables 4.18.0-553.16.1 commit-author Pablo Neira Ayuso <pablo@netfilter.org> commit a45e688 Unlike early commit path stage which triggers a call to abort, an explicit release of the batch is required on abort, otherwise mutex is released and commit_list remains in place. Add WARN_ON_ONCE to ensure commit_list is empty from the abort path before releasing the mutex. After this patch, commit_list is always assumed to be empty before grabbing the mutex, therefore 03c1f1e ("netfilter: Cleanup nft_net->module_list from nf_tables_exit_net()") only needs to release the pending modules for registration. Cc: stable@vger.kernel.org Fixes: c0391b6 ("netfilter: nf_tables: missing validation from the abort path") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit a45e688) Signed-off-by: Greg Rose <g.v.rose@ciq.com>

jira VULN-4905 cve CVE-2024-26925 commit-author Pablo Neira Ayuso <pablo@netfilter.org> commit 0d459e2 The commit mutex should not be released during the critical section between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC worker could collect expired objects and get the released commit lock within the same GC sequence. nf_tables_module_autoload() temporarily releases the mutex to load module dependencies, then it goes back to replay the transaction again. Move it at the end of the abort phase after nft_gc_seq_end() is called. Cc: stable@vger.kernel.org Fixes: 7203443 ("netfilter: nf_tables: GC transaction race with abort path") Reported-by: Kuan-Ting Chen <hexrabbit@devco.re> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 0d459e2) Signed-off-by: Greg Rose <g.v.rose@ciq.com>

jira VULN-4969 subsystem-sync netfilter:nf_tables 4.18.0-553.16.1 commit-author Pablo Neira Ayuso <pablo@netfilter.org> commit 9cff126 In case that there are two types, prefer the family specify extension. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 9cff126) Signed-off-by: Greg Rose <g.v.rose@ciq.com>

gvrose8192 · 2024-11-13T23:48:13Z

The commit message here: d9a8f26
jira VULN-4905
cve CVE-2024-27020
commit-author Ziyang Xuan <william.xuanziyang@huawei.com>
commit https://github.com/ctrliq/kernel-src-tree/commit/f969eb84ce482331a991079ab7a5c4dc3b7f89bf
The ticket number is wrong for the CVECVE-2024-27020, it should be VULN-4969

This is what happens with command line editing when you forget to update all the necessary fields for the previous command. Fixed in the upcoming push.

jira VULN-4969 cve CVE-2024-27020 commit-author Ziyang Xuan <william.xuanziyang@huawei.com> commit f969eb8 nft_unregister_expr() can concurrent with __nft_expr_type_get(), and there is not any protection when iterate over nf_tables_expressions list in __nft_expr_type_get(). Therefore, there is potential data-race of nf_tables_expressions list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_expressions list in __nft_expr_type_get(), and use rcu_read_lock() in the caller nft_expr_type_get() to protect the entire type query process. Fixes: ef1f7df ("netfilter: nf_tables: expression ops overloading") Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit f969eb8) Signed-off-by: Greg Rose <g.v.rose@ciq.com>

jira VULN-4961 cve CVE-2024-27019 commit-author Ziyang Xuan <william.xuanziyang@huawei.com> commit d78d867 upstream-diff The cherry-pick tried to pull in extra cruft not part of the upstream patch. I have resolved the conflicts in favor of the 4.18.0-553.16.1 tagged code. nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process. Fixes: e500924 ("netfilter: nf_tables: add stateful objects") Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit d78d867) Signed-off-by: Greg Rose <g.v.rose@ciq.com> Conflicts: net/netfilter/nf_tables_api.c

jira VULN-4985 cve CVE-2024-27065 commit-author Pablo Neira Ayuso <pablo@netfilter.org> commit 4a0e7f2 Restore skipping transaction if table update does not modify flags. Fixes: 179d9ba ("netfilter: nf_tables: fix table flag updates") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 4a0e7f2) Signed-off-by: Greg Rose <g.v.rose@ciq.com>

jira VULN-5126 cve CVE-2024-35899 commit-author Pablo Neira Ayuso <pablo@netfilter.org> commit 24cea96 Similar to 2c9f029 ("netfilter: nf_tables: flush pending destroy work before netlink notifier") to address a race between exit_net and the destroy workqueue. The trace below shows an element to be released via destroy workqueue while exit_net path (triggered via module removal) has already released the set that is used in such transaction. [ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables] [ 1360.547984] Call Trace: [ 1360.547991] <TASK> [ 1360.547998] dump_stack_lvl+0x53/0x70 [ 1360.548014] print_report+0xc4/0x610 [ 1360.548026] ? __virt_addr_valid+0xba/0x160 [ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548176] kasan_report+0xae/0xe0 [ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables] [ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30 [ 1360.548591] process_one_work+0x2f1/0x670 [ 1360.548610] worker_thread+0x4d3/0x760 [ 1360.548627] ? __pfx_worker_thread+0x10/0x10 [ 1360.548640] kthread+0x16b/0x1b0 [ 1360.548653] ? __pfx_kthread+0x10/0x10 [ 1360.548665] ret_from_fork+0x2f/0x50 [ 1360.548679] ? __pfx_kthread+0x10/0x10 [ 1360.548690] ret_from_fork_asm+0x1a/0x30 [ 1360.548707] </TASK> [ 1360.548719] Allocated by task 192061: [ 1360.548726] kasan_save_stack+0x20/0x40 [ 1360.548739] kasan_save_track+0x14/0x30 [ 1360.548750] __kasan_kmalloc+0x8f/0xa0 [ 1360.548760] __kmalloc_node+0x1f1/0x450 [ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables] [ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink] [ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink] [ 1360.548927] netlink_unicast+0x367/0x4f0 [ 1360.548935] netlink_sendmsg+0x34b/0x610 [ 1360.548944] ____sys_sendmsg+0x4d4/0x510 [ 1360.548953] ___sys_sendmsg+0xc9/0x120 [ 1360.548961] __sys_sendmsg+0xbe/0x140 [ 1360.548971] do_syscall_64+0x55/0x120 [ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 1360.548994] Freed by task 192222: [ 1360.548999] kasan_save_stack+0x20/0x40 [ 1360.549009] kasan_save_track+0x14/0x30 [ 1360.549019] kasan_save_free_info+0x3b/0x60 [ 1360.549028] poison_slab_object+0x100/0x180 [ 1360.549036] __kasan_slab_free+0x14/0x30 [ 1360.549042] kfree+0xb6/0x260 [ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables] [ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables] [ 1360.549221] ops_exit_list+0x50/0xa0 [ 1360.549229] free_exit_list+0x101/0x140 [ 1360.549236] unregister_pernet_operations+0x107/0x160 [ 1360.549245] unregister_pernet_subsys+0x1c/0x30 [ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables] [ 1360.549345] __do_sys_delete_module+0x253/0x370 [ 1360.549352] do_syscall_64+0x55/0x120 [ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d (gdb) list *__nft_release_table+0x473 0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354). 11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) { 11350 list_del(&flowtable->list); 11351 nft_use_dec(&table->use); 11352 nf_tables_flowtable_destroy(flowtable); 11353 } 11354 list_for_each_entry_safe(set, ns, &table->sets, list) { 11355 list_del(&set->list); 11356 nft_use_dec(&table->use); 11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT)) 11358 nft_map_deactivate(&ctx, set); (gdb) [ 1360.549372] Last potentially related work creation: [ 1360.549376] kasan_save_stack+0x20/0x40 [ 1360.549384] __kasan_record_aux_stack+0x9b/0xb0 [ 1360.549392] __queue_work+0x3fb/0x780 [ 1360.549399] queue_work_on+0x4f/0x60 [ 1360.549407] nft_rhash_remove+0x33b/0x340 [nf_tables] [ 1360.549516] nf_tables_commit+0x1c6a/0x2620 [nf_tables] [ 1360.549625] nfnetlink_rcv_batch+0x728/0xdc0 [nfnetlink] [ 1360.549647] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink] [ 1360.549671] netlink_unicast+0x367/0x4f0 [ 1360.549680] netlink_sendmsg+0x34b/0x610 [ 1360.549690] ____sys_sendmsg+0x4d4/0x510 [ 1360.549697] ___sys_sendmsg+0xc9/0x120 [ 1360.549706] __sys_sendmsg+0xbe/0x140 [ 1360.549715] do_syscall_64+0x55/0x120 [ 1360.549725] entry_SYSCALL_64_after_hwframe+0x55/0x5d Fixes: 0935d55 ("netfilter: nf_tables: asynchronous release") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 24cea96) Signed-off-by: Greg Rose <g.v.rose@ciq.com>

jira VULN-5134 cve CVE-2024-35900 commit-author Pablo Neira Ayuso <pablo@netfilter.org> commit 994209d upstream-diff Fixed up a couple of small conflicts introduced by cherry picking from a very new source back into an ancient source. When dormant flag is toggled, hooks are disabled in the commit phase by iterating over current chains in table (existing and new). The following configuration allows for an inconsistent state: add table x add chain x y { type filter hook input priority 0; } add table x { flags dormant; } add chain x w { type filter hook input priority 1; } which triggers the following warning when trying to unregister chain w which is already unregistered. [ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260 [...] [ 127.322519] Call Trace: [ 127.322521] <TASK> [ 127.322524] ? __warn+0x9f/0x1a0 [ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260 [ 127.322537] ? report_bug+0x1b1/0x1e0 [ 127.322545] ? handle_bug+0x3c/0x70 [ 127.322552] ? exc_invalid_op+0x17/0x40 [ 127.322556] ? asm_exc_invalid_op+0x1a/0x20 [ 127.322563] ? kasan_save_free_info+0x3b/0x60 [ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260 [ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260 [ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260 [ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables] [ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables] [ 127.322717] nf_tables_commit+0x2571/0x2620 [nf_tables] Fixes: 179d9ba ("netfilter: nf_tables: fix table flag updates") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 994209d) Signed-off-by: Greg Rose <g.v.rose@ciq.com> Conflicts: net/netfilter/nf_tables_api.c

gvrose8192 · 2024-11-14T00:02:01Z

I'm still working on the addition of the empty commit "netfilter: nf_tables: reject table flag and netdev basechain updates" - as per our earlier conversation on slack. Stay tuned, just wanted to save this work.

To clarify - this push has all code swaps and changes as brought up in comments and I wanted to get that checked and then be able to run tests on it. The rework of the last commit into an empty commit and then the final commit is separate work that will not change the final code base. So I get an early jump on code testing here.

gvrose8192 · 2024-11-14T01:08:05Z

After further work and inspection, I have found that I made an error in bringing in upstream commits. These specifically:
1e1fb6f "netfilter: nf_tables: reject table flag and netdev basechain updates"

1bc83a0 "netfilter: nf_tables: discard table flag update with pending basechain deletion"

I reverse ordered them in the original push - I'm prone to that sort of thing. Glad we caught it, but took me a while to figure out my weird reverse ordered thinking. I hope it's fixed and more orderly now

jira VULN-5118 subsystem-sync netfilter:nf_tables 4.18.0-553.16.1 commit-author Pablo Neira Ayuso <pablo@netfilter.org> commit 1e1fb6f upstream-diff The upstream diff brings in cruft we don't want, and will be superseded by the next commit but is here to maintain history. netdev basechain updates are stored in the transaction object hook list. When setting on the table dormant flag, it iterates over the existing hooks in the basechain. Thus, skipping the hooks that are being added/deleted in this transaction, which leaves hook registration in inconsistent state. Reject table flag updates in combination with netdev basechain updates in the same batch: - Update table flags and add/delete basechain: Check from basechain update path if there are pending flag updates for this table. - add/delete basechain and update table flags: Iterate over the transaction list to search for basechain updates from the table update path. In both cases, the batch is rejected. Based on suggestion from Florian Westphal. Fixes: b9703ed ("netfilter: nf_tables: support for adding new devices to an existing netdev chain") Fixes: 7d937b1 ("netfilter: nf_tables: support for deleting devices in an existing netdev chain") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 1e1fb6f) Signed-off-by: Greg Rose <g.v.rose@ciq.com> Conflicts: net/netfilter/nf_tables_api.c

…n deletion jira VULN-5118 cve CVE-2024-35897 commit-author Pablo Neira Ayuso <pablo@netfilter.org> commit 1bc83a0 Hook unregistration is deferred to the commit phase, same occurs with hook updates triggered by the table dormant flag. When both commands are combined, this results in deleting a basechain while leaving its hook still registered in the core. Fixes: 179d9ba ("netfilter: nf_tables: fix table flag updates") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 1bc83a0) Signed-off-by: Greg Rose <g.v.rose@ciq.com>

ghost

Thanks for the updates. Looks good

gvrose8192 requested a review from PlaidCat November 12, 2024 22:26

gvrose8192 self-assigned this Nov 12, 2024

PlaidCat reviewed Nov 13, 2024

View reviewed changes

Comment thread net/netfilter/nf_tables_api.c

PlaidCat reviewed Nov 13, 2024

View reviewed changes

Comment thread net/netfilter/nf_tables_api.c

gvrose8192 added 3 commits November 13, 2024 15:18

gvrose8192 added 5 commits November 13, 2024 15:50

gvrose8192 force-pushed the gvrose_fips-legacy-8-compliant_4.18.0-425.13.1 branch from 878b073 to 00da01d Compare November 13, 2024 23:51

gvrose8192 force-pushed the gvrose_fips-legacy-8-compliant_4.18.0-425.13.1 branch from 00da01d to c91d829 Compare November 14, 2024 01:03

PlaidCat reviewed Nov 14, 2024

View reviewed changes

Comment thread net/netfilter/nf_tables_api.c Outdated

PlaidCat reviewed Nov 14, 2024

View reviewed changes

Comment thread net/netfilter/nf_tables_api.c Outdated

gvrose8192 added 2 commits November 14, 2024 08:45

gvrose8192 force-pushed the gvrose_fips-legacy-8-compliant_4.18.0-425.13.1 branch from c91d829 to 04f10f1 Compare November 14, 2024 17:13

PlaidCat approved these changes Nov 14, 2024

View reviewed changes

gvrose8192 merged commit 0c3116e into fips-legacy-8-compliant/4.18.0-425.13.1 Nov 14, 2024

gvrose8192 deleted the gvrose_fips-legacy-8-compliant_4.18.0-425.13.1 branch November 14, 2024 19:16

PlaidCat mentioned this pull request Nov 22, 2024

Sync fips legacy 8 compliant 4.18.0 425.13.1.el8.ciqfipscompliant.36.1 ciq-rocky-fips/kernel#15

Open

gvrose8192 mentioned this pull request Dec 5, 2024

CVE-2023-2163 kernel lts-9.2 fix #19

Merged

Navigation Menu

PR for completion of LE-2004 - #8

PR for completion of LE-2004#8
gvrose8192 merged 11 commits into
fips-legacy-8-compliant/4.18.0-425.13.1from
gvrose_fips-legacy-8-compliant_4.18.0-425.13.1

gvrose8192 commented Nov 12, 2024 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

PlaidCat commented Nov 13, 2024

Uh oh!

gvrose8192 commented Nov 13, 2024

Uh oh!

gvrose8192 commented Nov 14, 2024 •

edited

Loading

Uh oh!

gvrose8192 commented Nov 14, 2024

Uh oh!

Uh oh!

Uh oh!

ghost left a comment •

edited by PlaidCat

Loading

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

Conversation

gvrose8192 commented Nov 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

PlaidCat commented Nov 13, 2024

Uh oh!

gvrose8192 commented Nov 13, 2024

Uh oh!

gvrose8192 commented Nov 14, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gvrose8192 commented Nov 14, 2024

Uh oh!

Uh oh!

Uh oh!

ghost left a comment • edited by PlaidCat Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

gvrose8192 commented Nov 12, 2024 •

edited

Loading

gvrose8192 commented Nov 14, 2024 •

edited

Loading

ghost left a comment •

edited by PlaidCat

Loading