head 1.2; access; symbols pkgsrc-2025Q3:1.1.0.18 pkgsrc-2025Q3-base:1.1 pkgsrc-2025Q2:1.1.0.16 pkgsrc-2025Q2-base:1.1 pkgsrc-2025Q1:1.1.0.14 pkgsrc-2025Q1-base:1.1 pkgsrc-2024Q4:1.1.0.12 pkgsrc-2024Q4-base:1.1 pkgsrc-2024Q3:1.1.0.10 pkgsrc-2024Q3-base:1.1 pkgsrc-2024Q2:1.1.0.8 pkgsrc-2024Q2-base:1.1 pkgsrc-2024Q1:1.1.0.6 pkgsrc-2024Q1-base:1.1 pkgsrc-2023Q4:1.1.0.4 pkgsrc-2023Q4-base:1.1 pkgsrc-2023Q3:1.1.0.2; locks; strict; comment @# @; 1.2 date 2025.10.21.13.42.57; author bouyer; state dead; branches; next 1.1; commitid 7iYGhItznjMPorfG; 1.1 date 2023.11.15.15.59.36; author bouyer; state Exp; branches 1.1.2.1; next ; commitid ChAJVaTOI2nkQIME; 1.1.2.1 date 2023.11.15.15.59.36; author bsiegert; state dead; branches; next 1.1.2.2; commitid GoFxWjHbRICPvANE; 1.1.2.2 date 2023.11.22.09.37.25; author bsiegert; state Exp; branches; next ; commitid GoFxWjHbRICPvANE; desc @@ 1.2 log @remove xenkernel415 and xentools415. Xen 4.15 is EOL upstream @ text @$NetBSD: patch-XSA440,v 1.1 2023/11/15 15:59:36 bouyer Exp $ From 5d8b3d1ec98e56155d9650d7f4a70cd8ba9dc27d Mon Sep 17 00:00:00 2001 From: Julien Grall Date: Fri, 22 Sep 2023 11:32:16 +0100 Subject: tools/xenstored: domain_entry_fix(): Handle conflicting transaction The function domain_entry_fix() will be initially called to check if the quota is correct before attempt to commit any nodes. So it would be possible that accounting is temporarily negative. This is the case in the following sequence: 1) Create 50 nodes 2) Start two transactions 3) Delete all the nodes in each transaction 4) Commit the two transactions Because the first transaction will have succeed and updated the accounting, there is no guarantee that 'd->nbentry + num' will still be above 0. So the assert() would be triggered. The assert() was introduced in dbef1f748289 ("tools/xenstore: simplify and fix per domain node accounting") with the assumption that the value can't be negative. As this is not true revert to the original check but restricted to the path where we don't update. Take the opportunity to explain the rationale behind the check. This CVE-2023-34323 / XSA-440. Reported-by: Stanislav Uschakow Fixes: dbef1f748289 ("tools/xenstore: simplify and fix per domain node accounting") Signed-off-by: Julien Grall Reviewed-by: Juergen Gross diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c index aa86892fed9e..6074df210c6e 100644 --- tools/xenstore/xenstored_domain.c.orig +++ tools/xenstore/xenstored_domain.c @@@@ -1094,10 +1094,20 @@@@ int domain_entry_fix(unsigned int domid, int num, bool update) } cnt = d->nbentry + num; - assert(cnt >= 0); - if (update) + if (update) { + assert(cnt >= 0); d->nbentry = cnt; + } else if (cnt < 0) { + /* + * In a transaction when a node is being added/removed AND + * the same node has been added/removed outside the + * transaction in parallel, the result value may be negative. + * This is no problem, as the transaction will fail due to + * the resulting conflict. So override 'cnt'. + */ + cnt = 0; + } return domid_is_unprivileged(domid) ? cnt : 0; } @ 1.1 log @xen*415: apply upstream patches for Xen Security Advisory XSA-439, XSA-440, XSA-442, XSA-443, XSA-444, XSA-445, XSA-446 bump PKGREVISIONs @ text @d1 1 a1 1 $NetBSD: $ @ 1.1.2.1 log @file patch-XSA440 was added on branch pkgsrc-2023Q3 on 2023-11-22 09:37:25 +0000 @ text @d1 60 @ 1.1.2.2 log @Pullup ticket #6823 - requested by bouyer sysutils/xenkernel415: security fix sysutils/xentools415: security fix Revisions pulled up: - sysutils/xenkernel415/Makefile 1.12 - sysutils/xenkernel415/distinfo 1.11 - sysutils/xenkernel415/patches/patch-XSA439 1.1 - sysutils/xenkernel415/patches/patch-XSA442 1.1 - sysutils/xenkernel415/patches/patch-XSA444 1.1 - sysutils/xenkernel415/patches/patch-XSA445 1.1 - sysutils/xenkernel415/patches/patch-XSA446 1.1 - sysutils/xentools415/Makefile 1.28 - sysutils/xentools415/PLIST 1.4 - sysutils/xentools415/distinfo 1.14 - sysutils/xentools415/patches/patch-XSA440 1.1 - sysutils/xentools415/patches/patch-XSA443 1.1 --- Module Name: pkgsrc Committed By: bouyer Date: Wed Nov 15 15:59:36 UTC 2023 Modified Files: pkgsrc/sysutils/xenkernel415: Makefile distinfo pkgsrc/sysutils/xentools415: Makefile PLIST distinfo Added Files: pkgsrc/sysutils/xenkernel415/patches: patch-XSA439 patch-XSA442 patch-XSA444 patch-XSA445 patch-XSA446 pkgsrc/sysutils/xentools415/patches: patch-XSA440 patch-XSA443 Log Message: xen*415: apply upstream patches for Xen Security Advisory XSA-439, XSA-440, XSA-442, XSA-443, XSA-444, XSA-445, XSA-446 bump PKGREVISIONs @ text @a0 60 $NetBSD: patch-XSA440,v 1.1 2023/11/15 15:59:36 bouyer Exp $ From 5d8b3d1ec98e56155d9650d7f4a70cd8ba9dc27d Mon Sep 17 00:00:00 2001 From: Julien Grall Date: Fri, 22 Sep 2023 11:32:16 +0100 Subject: tools/xenstored: domain_entry_fix(): Handle conflicting transaction The function domain_entry_fix() will be initially called to check if the quota is correct before attempt to commit any nodes. So it would be possible that accounting is temporarily negative. This is the case in the following sequence: 1) Create 50 nodes 2) Start two transactions 3) Delete all the nodes in each transaction 4) Commit the two transactions Because the first transaction will have succeed and updated the accounting, there is no guarantee that 'd->nbentry + num' will still be above 0. So the assert() would be triggered. The assert() was introduced in dbef1f748289 ("tools/xenstore: simplify and fix per domain node accounting") with the assumption that the value can't be negative. As this is not true revert to the original check but restricted to the path where we don't update. Take the opportunity to explain the rationale behind the check. This CVE-2023-34323 / XSA-440. Reported-by: Stanislav Uschakow Fixes: dbef1f748289 ("tools/xenstore: simplify and fix per domain node accounting") Signed-off-by: Julien Grall Reviewed-by: Juergen Gross diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c index aa86892fed9e..6074df210c6e 100644 --- tools/xenstore/xenstored_domain.c.orig +++ tools/xenstore/xenstored_domain.c @@@@ -1094,10 +1094,20 @@@@ int domain_entry_fix(unsigned int domid, int num, bool update) } cnt = d->nbentry + num; - assert(cnt >= 0); - if (update) + if (update) { + assert(cnt >= 0); d->nbentry = cnt; + } else if (cnt < 0) { + /* + * In a transaction when a node is being added/removed AND + * the same node has been added/removed outside the + * transaction in parallel, the result value may be negative. + * This is no problem, as the transaction will fail due to + * the resulting conflict. So override 'cnt'. + */ + cnt = 0; + } return domid_is_unprivileged(domid) ? cnt : 0; } @