There's an I/O error on fsync() in a detached loop device
if it has been previously attached.
The issue is write cache is enabled in the attach path in
loop_configure() but it isn't disabled in the detach path;
thus it remains enabled in the block device regardless of
whether it is attached or not.
Now fsync() can get an I/O request that will just be failed
later in loop_queue_rq() as device's state is not 'Lo_bound'.
So, disable write cache in the detach path.
Do so based on the queue flag, not the loop device flag for
read-only (used to enable) as the queue flag can be changed
via sysfs even on read-only loop devices (e.g., losetup -r.)
Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend")
Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
Reviewed-by: Michal Swiatkowski <email address hidden>
Signed-off-by: Eric Van Hensbergen <email address hidden>
CVE-2023-1859
(cherry picked from commit ea4f1009408efb4989a0f139b70fb338e7f687d0)
Signed-off-by: John Cabaj <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: John Cabaj <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
xirc2ps_cs: Fix use after free bug in xirc2ps_detach
In xirc2ps_probe, the local->tx_timeout_task was bounded
with xirc2ps_tx_timeout_task. When timeout occurs,
it will call xirc_tx_timeout->schedule_work to start the
work.
When we call xirc2ps_detach to remove the driver, there
may be a sequence as follows:
Stop responding to timeout tasks and complete scheduled
tasks before cleanup in xirc2ps_detach, which will fix
the problem.
Ignore: yes
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
fab948a...
by
Pablo Neira Ayuso <email address hidden>
netfilter: nf_tables: deactivate anonymous set from preparation phase
Toggle deleted anonymous sets as inactive in the next generation, so
users cannot perform any update on it. Clear the generation bitmask
in case the transaction is aborted.
The following KASAN splat shows a set element deletion for a bound
anonymous set that has been already removed in the same transaction.
Signed-off-by: Pablo Neira Ayuso <email address hidden>
(cherry picked from commit c1592a89942e9678f7d9c8030efa777c0d57edab)
CVE-2023-32233
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Andrei Gherzan <email address hidden>
Acked-by: Cory Todd <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
f732c2c...
by
Pablo Neira Ayuso <email address hidden>
netfilter: nf_tables: use-after-free in failing rule with bound set
If a rule that has already a bound anonymous set fails to be added, the
preparation phase releases the rule and the bound set. However, the
transaction object from the abort path still has a reference to the set
object that is stale, leading to a use-after-free when checking for the
set->bound field. Add a new field to the transaction that specifies if
the set is bound, so the abort path can skip releasing it since the rule
command owns it and it takes care of releasing it. After this update,
the set->bound field is removed.
Fixes: f6ac85858976 ("netfilter: nf_tables: unbind set in rule from commit path")
Signed-off-by: Pablo Neira Ayuso <email address hidden>
(cherry picked from commit 6a0a8d10a3661a036b55af695542a714c429ab7c)
CVE-2023-32233
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Andrei Gherzan <email address hidden>
Acked-by: Cory Todd <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
97cb26e...
by
Pablo Neira Ayuso <email address hidden>
netfilter: nf_tables: bogus EBUSY when deleting set after flush
Set deletion after flush coming in the same batch results in EBUSY. Add
set use counter to track the number of references to this set from
rules. We cannot rely on the list of bindings for this since such list
is still populated from the preparation phase.
Reported-by: Václav Zindulka <email address hidden>
Signed-off-by: Pablo Neira Ayuso <email address hidden>
(backported from commit 273fe3f1006ea5ebc63d6729e43e8e45e32b256a)
[cascardo: small conflict due to missing extended ACKs (NL_SET_BAD_ATTR)]
CVE-2023-32233
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Andrei Gherzan <email address hidden>
Acked-by: Cory Todd <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>