lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 22 Sep 2017 18:48:42 -0400 From: Boris Ostrovsky <boris.ostrovsky@...cle.com> To: Stefano Stabellini <sstabellini@...nel.org>, xen-devel@...ts.xen.org Cc: linux-kernel@...r.kernel.org, jgross@...e.com, Stefano Stabellini <stefano@...reto.com> Subject: Re: [PATCH v4 12/13] xen/pvcalls: implement release command >> + */ >> + map->active.ring->in_error = -EBADF; >> + wake_up_interruptible(&map->active.inflight_conn_req); >> + >> + /* >> + * Wait until there are no more waiters on the mutexes. >> + * We know that no new waiters can be added because sk_send_head >> + * is set to NULL -- we only need to wait for the existing >> + * waiters to return. >> + */ >> + while (!mutex_trylock(&map->active.in_mutex) || >> + !mutex_trylock(&map->active.out_mutex)) >> + cpu_relax(); > > What if you manage to grab the locks before waiters get to run? for > example, in recvmsg: > > while (!(flags & MSG_DONTWAIT) && !pvcalls_front_read_todo(map)) { > wait_event_interruptible(map->active.inflight_conn_req, > pvcalls_front_read_todo(map)); > } > ret = __read_ring(map->active.ring, &map->active.data, > &msg->msg_iter, len, flags); > > map will be freed (by pvcalls_front_free_map() below) before __read_ring > is passed the just-freed ring. Actually, since you don't drop the locks I am not sure recvmsg side will even get there. -boris > > >> + >> + pvcalls_front_free_map(bedata, map); >> + kfree(map); > > -boris > >
Powered by blists - more mailing lists