* [PULL 0/5] 9p queue 2022-02-10 @ 2022-02-10 11:21 Christian Schoenebeck 2022-02-10 11:21 ` [PULL 3/5] tests/9pfs: Fix leak of local_test_path Christian Schoenebeck ` (5 more replies) 0 siblings, 6 replies; 20+ messages in thread From: Christian Schoenebeck @ 2022-02-10 11:21 UTC (permalink / raw) To: qemu-devel, Peter Maydell; +Cc: Greg Kurz The following changes since commit 0a301624c2f4ced3331ffd5bce85b4274fe132af: Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20220208' into staging (2022-02-08 11:40:08 +0000) are available in the Git repository at: https://github.com/cschoenebeck/qemu.git tags/pull-9p-20220210 for you to fetch changes up to de19c79dad6a2cad54ae04ce754d47c07bf9bc93: 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread (2022-02-10 11:56:01 +0100) ---------------------------------------------------------------- 9pfs: fixes and cleanup * Fifth patch fixes a 9pfs server crash that happened on some systems due to incorrect (system dependant) handling of struct dirent size. * Tests: Second patch fixes a test error that happened on some systems due mkdir() being called twice for creating the test directory for the 9p 'local' tests. * Tests: Third patch fixes a memory leak. * Tests: The remaining two patches are code cleanup. ---------------------------------------------------------------- Christian Schoenebeck (2): tests/9pfs: use g_autofree where possible tests/9pfs: fix mkdir() being called twice Greg Kurz (2): tests/9pfs: Fix leak of local_test_path tests/9pfs: Use g_autofree and g_autoptr where possible Vitaly Chikunov (1): 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread hw/9pfs/codir.c | 3 +- include/qemu/osdep.h | 13 ++++++ tests/qtest/libqos/virtio-9p.c | 38 +++++++----------- tests/qtest/virtio-9p-test.c | 90 +++++++++++++----------------------------- util/osdep.c | 21 ++++++++++ 5 files changed, 76 insertions(+), 89 deletions(-) ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PULL 3/5] tests/9pfs: Fix leak of local_test_path 2022-02-10 11:21 [PULL 0/5] 9p queue 2022-02-10 Christian Schoenebeck @ 2022-02-10 11:21 ` Christian Schoenebeck 2022-02-10 11:21 ` [PULL 5/5] 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread Christian Schoenebeck ` (4 subsequent siblings) 5 siblings, 0 replies; 20+ messages in thread From: Christian Schoenebeck @ 2022-02-10 11:21 UTC (permalink / raw) To: qemu-devel, Peter Maydell; +Cc: Greg Kurz From: Greg Kurz <groug@kaod.org> local_test_path is allocated in virtio_9p_create_local_test_dir() to hold the path of the temporary directory. It should be freed in virtio_9p_remove_local_test_dir() when the temporary directory is removed. Clarify the lifecycle of local_test_path while here. Based-on: <f6602123c6f7d0d593466231b04fba087817abbd.1642879848.git.qemu_oss@crudebyte.com> Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <20220201151508.190035-2-groug@kaod.org> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> --- tests/qtest/libqos/virtio-9p.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/tests/qtest/libqos/virtio-9p.c b/tests/qtest/libqos/virtio-9p.c index ef96ef006a..5d18e5eae5 100644 --- a/tests/qtest/libqos/virtio-9p.c +++ b/tests/qtest/libqos/virtio-9p.c @@ -39,8 +39,13 @@ static char *concat_path(const char* a, const char* b) void virtio_9p_create_local_test_dir(void) { + g_assert(local_test_path == NULL); struct stat st; char *pwd = g_get_current_dir(); + /* + * template gets cached into local_test_path and freed in + * virtio_9p_remove_local_test_dir(). + */ char *template = concat_path(pwd, "qtest-9p-local-XXXXXX"); local_test_path = mkdtemp(template); @@ -66,6 +71,8 @@ void virtio_9p_remove_local_test_dir(void) /* ignore error, dummy check to prevent compiler error */ } g_free(cmd); + g_free(local_test_path); + local_test_path = NULL; } char *virtio_9p_test_path(const char *path) -- 2.20.1 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PULL 5/5] 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread 2022-02-10 11:21 [PULL 0/5] 9p queue 2022-02-10 Christian Schoenebeck 2022-02-10 11:21 ` [PULL 3/5] tests/9pfs: Fix leak of local_test_path Christian Schoenebeck @ 2022-02-10 11:21 ` Christian Schoenebeck 2022-02-10 11:21 ` [PULL 2/5] tests/9pfs: fix mkdir() being called twice Christian Schoenebeck ` (3 subsequent siblings) 5 siblings, 0 replies; 20+ messages in thread From: Christian Schoenebeck @ 2022-02-10 11:21 UTC (permalink / raw) To: qemu-devel, Peter Maydell; +Cc: Greg Kurz From: Vitaly Chikunov <vt@altlinux.org> `struct dirent' returned from readdir(3) could be shorter (or longer) than `sizeof(struct dirent)', thus memcpy of sizeof length will overread into unallocated page causing SIGSEGV. Example stack trace: #0 0x00005555559ebeed v9fs_co_readdir_many (/usr/bin/qemu-system-x86_64 + 0x497eed) #1 0x00005555559ec2e9 v9fs_readdir (/usr/bin/qemu-system-x86_64 + 0x4982e9) #2 0x0000555555eb7983 coroutine_trampoline (/usr/bin/qemu-system-x86_64 + 0x963983) #3 0x00007ffff73e0be0 n/a (n/a + 0x0) While fixing, provide a helper for any future `struct dirent' cloning. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/841 Cc: qemu-stable@nongnu.org Co-authored-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Vitaly Chikunov <vt@altlinux.org> Acked-by: Greg Kurz <groug@kaod.org> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <20220206013419.849161-1-vt@altlinux.org> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> --- hw/9pfs/codir.c | 3 +-- include/qemu/osdep.h | 13 +++++++++++++ util/osdep.c | 21 +++++++++++++++++++++ 3 files changed, 35 insertions(+), 2 deletions(-) diff --git a/hw/9pfs/codir.c b/hw/9pfs/codir.c index 032cce04c4..c0873bde16 100644 --- a/hw/9pfs/codir.c +++ b/hw/9pfs/codir.c @@ -143,8 +143,7 @@ static int do_readdir_many(V9fsPDU *pdu, V9fsFidState *fidp, } else { e = e->next = g_malloc0(sizeof(V9fsDirEnt)); } - e->dent = g_malloc0(sizeof(struct dirent)); - memcpy(e->dent, dent, sizeof(struct dirent)); + e->dent = qemu_dirent_dup(dent); /* perform a full stat() for directory entry if requested by caller */ if (dostat) { diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h index d1660d67fa..ce12f64853 100644 --- a/include/qemu/osdep.h +++ b/include/qemu/osdep.h @@ -805,6 +805,19 @@ static inline int platform_does_not_support_system(const char *command) } #endif /* !HAVE_SYSTEM_FUNCTION */ +/** + * Duplicate directory entry @dent. + * + * It is highly recommended to use this function instead of open coding + * duplication of @c dirent objects, because the actual @c struct @c dirent + * size may be bigger or shorter than @c sizeof(struct dirent) and correct + * handling is platform specific (see gitlab issue #841). + * + * @dent - original directory entry to be duplicated + * @returns duplicated directory entry which should be freed with g_free() + */ +struct dirent *qemu_dirent_dup(struct dirent *dent); + #ifdef __cplusplus } #endif diff --git a/util/osdep.c b/util/osdep.c index 42a0a4986a..67fbf22778 100644 --- a/util/osdep.c +++ b/util/osdep.c @@ -33,6 +33,7 @@ extern int madvise(char *, size_t, int); #endif +#include <dirent.h> #include "qemu-common.h" #include "qemu/cutils.h" #include "qemu/sockets.h" @@ -615,3 +616,23 @@ writev(int fd, const struct iovec *iov, int iov_cnt) return readv_writev(fd, iov, iov_cnt, true); } #endif + +struct dirent * +qemu_dirent_dup(struct dirent *dent) +{ + size_t sz = 0; +#if defined _DIRENT_HAVE_D_RECLEN + /* Avoid use of strlen() if platform supports d_reclen. */ + sz = dent->d_reclen; +#endif + /* + * Test sz for zero even if d_reclen is available + * because some drivers may set d_reclen to zero. + */ + if (sz == 0) { + /* Fallback to the most portable way. */ + sz = offsetof(struct dirent, d_name) + + strlen(dent->d_name) + 1; + } + return g_memdup(dent, sz); +} -- 2.20.1 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PULL 2/5] tests/9pfs: fix mkdir() being called twice 2022-02-10 11:21 [PULL 0/5] 9p queue 2022-02-10 Christian Schoenebeck 2022-02-10 11:21 ` [PULL 3/5] tests/9pfs: Fix leak of local_test_path Christian Schoenebeck 2022-02-10 11:21 ` [PULL 5/5] 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread Christian Schoenebeck @ 2022-02-10 11:21 ` Christian Schoenebeck 2022-02-10 11:21 ` [PULL 1/5] tests/9pfs: use g_autofree where possible Christian Schoenebeck ` (2 subsequent siblings) 5 siblings, 0 replies; 20+ messages in thread From: Christian Schoenebeck @ 2022-02-10 11:21 UTC (permalink / raw) To: qemu-devel, Peter Maydell; +Cc: Greg Kurz The 9p test cases use mkdtemp() to create a temporary directory for running the 'local' 9p tests with real files/dirs. Unlike mktemp() which only generates a unique file name, mkdtemp() also creates the directory, therefore the subsequent mkdir() was wrong and caused errors on some systems. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Fixes: 136b7af2 (tests/9pfs: fix test dir for parallel tests) Reported-by: Daniel P. Berrangé <berrange@redhat.com> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/832 Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Greg Kurz <Greg Kurz <groug@kaod.org> Message-Id: <f6602123c6f7d0d593466231b04fba087817abbd.1642879848.git.qemu_oss@crudebyte.com> --- tests/qtest/libqos/virtio-9p.c | 18 +++--------------- 1 file changed, 3 insertions(+), 15 deletions(-) diff --git a/tests/qtest/libqos/virtio-9p.c b/tests/qtest/libqos/virtio-9p.c index b4e1143288..ef96ef006a 100644 --- a/tests/qtest/libqos/virtio-9p.c +++ b/tests/qtest/libqos/virtio-9p.c @@ -37,31 +37,19 @@ static char *concat_path(const char* a, const char* b) return g_build_filename(a, b, NULL); } -static void init_local_test_path(void) +void virtio_9p_create_local_test_dir(void) { + struct stat st; char *pwd = g_get_current_dir(); char *template = concat_path(pwd, "qtest-9p-local-XXXXXX"); + local_test_path = mkdtemp(template); if (!local_test_path) { g_test_message("mkdtemp('%s') failed: %s", template, strerror(errno)); } - g_assert(local_test_path); g_free(pwd); -} - -void virtio_9p_create_local_test_dir(void) -{ - struct stat st; - int res; - - init_local_test_path(); g_assert(local_test_path != NULL); - res = mkdir(local_test_path, 0777); - if (res < 0) { - g_test_message("mkdir('%s') failed: %s", local_test_path, - strerror(errno)); - } /* ensure test directory exists now ... */ g_assert(stat(local_test_path, &st) == 0); -- 2.20.1 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PULL 1/5] tests/9pfs: use g_autofree where possible 2022-02-10 11:21 [PULL 0/5] 9p queue 2022-02-10 Christian Schoenebeck ` (2 preceding siblings ...) 2022-02-10 11:21 ` [PULL 2/5] tests/9pfs: fix mkdir() being called twice Christian Schoenebeck @ 2022-02-10 11:21 ` Christian Schoenebeck 2022-02-10 11:21 ` [PULL 4/5] tests/9pfs: Use g_autofree and g_autoptr " Christian Schoenebeck 2022-02-13 20:33 ` [PULL 0/5] 9p queue 2022-02-10 Peter Maydell 5 siblings, 0 replies; 20+ messages in thread From: Christian Schoenebeck @ 2022-02-10 11:21 UTC (permalink / raw) To: qemu-devel, Peter Maydell; +Cc: Greg Kurz Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <E1mn1fA-0005qZ-TM@lizzy.crudebyte.com> --- tests/qtest/virtio-9p-test.c | 90 +++++++++++------------------------- 1 file changed, 27 insertions(+), 63 deletions(-) diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c index 41fed41de1..502e5ad0c7 100644 --- a/tests/qtest/virtio-9p-test.c +++ b/tests/qtest/virtio-9p-test.c @@ -84,7 +84,7 @@ static void pci_config(void *obj, void *data, QGuestAllocator *t_alloc) QVirtio9P *v9p = obj; alloc = t_alloc; size_t tag_len = qvirtio_config_readw(v9p->vdev, 0); - char *tag; + g_autofree char *tag = NULL; int i; g_assert_cmpint(tag_len, ==, strlen(MOUNT_TAG)); @@ -94,7 +94,6 @@ static void pci_config(void *obj, void *data, QGuestAllocator *t_alloc) tag[i] = qvirtio_config_readb(v9p->vdev, i + 2); } g_assert_cmpmem(tag, tag_len, MOUNT_TAG, tag_len); - g_free(tag); } #define P9_MAX_SIZE 4096 /* Max size of a T-message or R-message */ @@ -580,7 +579,7 @@ static void do_version(QVirtio9P *v9p) { const char *version = "9P2000.L"; uint16_t server_len; - char *server_version; + g_autofree char *server_version = NULL; P9Req *req; req = v9fs_tversion(v9p, P9_MAX_SIZE, version, P9_NOTAG); @@ -588,8 +587,6 @@ static void do_version(QVirtio9P *v9p) v9fs_rversion(req, &server_len, &server_version); g_assert_cmpmem(server_version, server_len, version, strlen(version)); - - g_free(server_version); } /* utility function: walk to requested dir and return fid for that dir */ @@ -637,7 +634,7 @@ static void fs_walk(void *obj, void *data, QGuestAllocator *t_alloc) alloc = t_alloc; char *wnames[P9_MAXWELEM]; uint16_t nwqid; - v9fs_qid *wqid; + g_autofree v9fs_qid *wqid = NULL; int i; P9Req *req; @@ -655,8 +652,6 @@ static void fs_walk(void *obj, void *data, QGuestAllocator *t_alloc) for (i = 0; i < P9_MAXWELEM; i++) { g_free(wnames[i]); } - - g_free(wqid); } static bool fs_dirents_contain_name(struct V9fsDirent *e, const char* name) @@ -872,9 +867,9 @@ static void fs_readdir(void *obj, void *data, QGuestAllocator *t_alloc) g_assert_cmpint(fs_dirents_contain_name(entries, "."), ==, true); g_assert_cmpint(fs_dirents_contain_name(entries, ".."), ==, true); for (int i = 0; i < QTEST_V9FS_SYNTH_READDIR_NFILES; ++i) { - char *name = g_strdup_printf(QTEST_V9FS_SYNTH_READDIR_FILE, i); + g_autofree char *name = + g_strdup_printf(QTEST_V9FS_SYNTH_READDIR_FILE, i); g_assert_cmpint(fs_dirents_contain_name(entries, name), ==, true); - g_free(name); } v9fs_free_dirents(entries); @@ -984,7 +979,8 @@ static void fs_walk_dotdot(void *obj, void *data, QGuestAllocator *t_alloc) QVirtio9P *v9p = obj; alloc = t_alloc; char *const wnames[] = { g_strdup("..") }; - v9fs_qid root_qid, *wqid; + v9fs_qid root_qid; + g_autofree v9fs_qid *wqid = NULL; P9Req *req; do_version(v9p); @@ -998,7 +994,6 @@ static void fs_walk_dotdot(void *obj, void *data, QGuestAllocator *t_alloc) g_assert_cmpmem(&root_qid, 13, wqid[0], 13); - g_free(wqid); g_free(wnames[0]); } @@ -1027,7 +1022,7 @@ static void fs_write(void *obj, void *data, QGuestAllocator *t_alloc) alloc = t_alloc; static const uint32_t write_count = P9_MAX_SIZE / 2; char *const wnames[] = { g_strdup(QTEST_V9FS_SYNTH_WRITE_FILE) }; - char *buf = g_malloc0(write_count); + g_autofree char *buf = g_malloc0(write_count); uint32_t count; P9Req *req; @@ -1045,7 +1040,6 @@ static void fs_write(void *obj, void *data, QGuestAllocator *t_alloc) v9fs_rwrite(req, &count); g_assert_cmpint(count, ==, write_count); - g_free(buf); g_free(wnames[0]); } @@ -1125,7 +1119,7 @@ static void fs_flush_ignored(void *obj, void *data, QGuestAllocator *t_alloc) static void do_mkdir(QVirtio9P *v9p, const char *path, const char *cname) { - char *const name = g_strdup(cname); + g_autofree char *name = g_strdup(cname); uint32_t fid; P9Req *req; @@ -1134,15 +1128,13 @@ static void do_mkdir(QVirtio9P *v9p, const char *path, const char *cname) req = v9fs_tmkdir(v9p, fid, name, 0750, 0, 0); v9fs_req_wait_for_reply(req, NULL); v9fs_rmkdir(req, NULL); - - g_free(name); } /* create a regular file with Tlcreate and return file's fid */ static uint32_t do_lcreate(QVirtio9P *v9p, const char *path, const char *cname) { - char *const name = g_strdup(cname); + g_autofree char *name = g_strdup(cname); uint32_t fid; P9Req *req; @@ -1152,7 +1144,6 @@ static uint32_t do_lcreate(QVirtio9P *v9p, const char *path, v9fs_req_wait_for_reply(req, NULL); v9fs_rlcreate(req, NULL, NULL); - g_free(name); return fid; } @@ -1160,8 +1151,8 @@ static uint32_t do_lcreate(QVirtio9P *v9p, const char *path, static void do_symlink(QVirtio9P *v9p, const char *path, const char *clink, const char *to) { - char *const name = g_strdup(clink); - char *const dst = g_strdup(to); + g_autofree char *name = g_strdup(clink); + g_autofree char *dst = g_strdup(to); uint32_t fid; P9Req *req; @@ -1170,9 +1161,6 @@ static void do_symlink(QVirtio9P *v9p, const char *path, const char *clink, req = v9fs_tsymlink(v9p, fid, name, dst, 0, 0); v9fs_req_wait_for_reply(req, NULL); v9fs_rsymlink(req, NULL); - - g_free(dst); - g_free(name); } /* create a hard link named @a clink in directory @a path pointing to @a to */ @@ -1193,7 +1181,7 @@ static void do_hardlink(QVirtio9P *v9p, const char *path, const char *clink, static void do_unlinkat(QVirtio9P *v9p, const char *atpath, const char *rpath, uint32_t flags) { - char *const name = g_strdup(rpath); + g_autofree char *name = g_strdup(rpath); uint32_t fid; P9Req *req; @@ -1202,8 +1190,6 @@ static void do_unlinkat(QVirtio9P *v9p, const char *atpath, const char *rpath, req = v9fs_tunlinkat(v9p, fid, name, flags, 0); v9fs_req_wait_for_reply(req, NULL); v9fs_runlinkat(req); - - g_free(name); } static void fs_readdir_split_128(void *obj, void *data, @@ -1235,8 +1221,8 @@ static void fs_create_dir(void *obj, void *data, QGuestAllocator *t_alloc) QVirtio9P *v9p = obj; alloc = t_alloc; struct stat st; - char *root_path = virtio_9p_test_path(""); - char *new_dir = virtio_9p_test_path("01"); + g_autofree char *root_path = virtio_9p_test_path(""); + g_autofree char *new_dir = virtio_9p_test_path("01"); g_assert(root_path != NULL); @@ -1247,9 +1233,6 @@ static void fs_create_dir(void *obj, void *data, QGuestAllocator *t_alloc) g_assert(stat(new_dir, &st) == 0); /* ... and is actually a directory */ g_assert((st.st_mode & S_IFMT) == S_IFDIR); - - g_free(new_dir); - g_free(root_path); } static void fs_unlinkat_dir(void *obj, void *data, QGuestAllocator *t_alloc) @@ -1257,8 +1240,8 @@ static void fs_unlinkat_dir(void *obj, void *data, QGuestAllocator *t_alloc) QVirtio9P *v9p = obj; alloc = t_alloc; struct stat st; - char *root_path = virtio_9p_test_path(""); - char *new_dir = virtio_9p_test_path("02"); + g_autofree char *root_path = virtio_9p_test_path(""); + g_autofree char *new_dir = virtio_9p_test_path("02"); g_assert(root_path != NULL); @@ -1273,9 +1256,6 @@ static void fs_unlinkat_dir(void *obj, void *data, QGuestAllocator *t_alloc) do_unlinkat(v9p, "/", "02", AT_REMOVEDIR); /* directory should be gone now */ g_assert(stat(new_dir, &st) != 0); - - g_free(new_dir); - g_free(root_path); } static void fs_create_file(void *obj, void *data, QGuestAllocator *t_alloc) @@ -1283,7 +1263,7 @@ static void fs_create_file(void *obj, void *data, QGuestAllocator *t_alloc) QVirtio9P *v9p = obj; alloc = t_alloc; struct stat st; - char *new_file = virtio_9p_test_path("03/1st_file"); + g_autofree char *new_file = virtio_9p_test_path("03/1st_file"); do_attach(v9p); do_mkdir(v9p, "/", "03"); @@ -1293,8 +1273,6 @@ static void fs_create_file(void *obj, void *data, QGuestAllocator *t_alloc) g_assert(stat(new_file, &st) == 0); /* ... and is a regular file */ g_assert((st.st_mode & S_IFMT) == S_IFREG); - - g_free(new_file); } static void fs_unlinkat_file(void *obj, void *data, QGuestAllocator *t_alloc) @@ -1302,7 +1280,7 @@ static void fs_unlinkat_file(void *obj, void *data, QGuestAllocator *t_alloc) QVirtio9P *v9p = obj; alloc = t_alloc; struct stat st; - char *new_file = virtio_9p_test_path("04/doa_file"); + g_autofree char *new_file = virtio_9p_test_path("04/doa_file"); do_attach(v9p); do_mkdir(v9p, "/", "04"); @@ -1316,8 +1294,6 @@ static void fs_unlinkat_file(void *obj, void *data, QGuestAllocator *t_alloc) do_unlinkat(v9p, "04", "doa_file", 0); /* file should be gone now */ g_assert(stat(new_file, &st) != 0); - - g_free(new_file); } static void fs_symlink_file(void *obj, void *data, QGuestAllocator *t_alloc) @@ -1325,8 +1301,8 @@ static void fs_symlink_file(void *obj, void *data, QGuestAllocator *t_alloc) QVirtio9P *v9p = obj; alloc = t_alloc; struct stat st; - char *real_file = virtio_9p_test_path("05/real_file"); - char *symlink_file = virtio_9p_test_path("05/symlink_file"); + g_autofree char *real_file = virtio_9p_test_path("05/real_file"); + g_autofree char *symlink_file = virtio_9p_test_path("05/symlink_file"); do_attach(v9p); do_mkdir(v9p, "/", "05"); @@ -1338,9 +1314,6 @@ static void fs_symlink_file(void *obj, void *data, QGuestAllocator *t_alloc) /* check if created link exists now */ g_assert(stat(symlink_file, &st) == 0); - - g_free(symlink_file); - g_free(real_file); } static void fs_unlinkat_symlink(void *obj, void *data, @@ -1349,8 +1322,8 @@ static void fs_unlinkat_symlink(void *obj, void *data, QVirtio9P *v9p = obj; alloc = t_alloc; struct stat st; - char *real_file = virtio_9p_test_path("06/real_file"); - char *symlink_file = virtio_9p_test_path("06/symlink_file"); + g_autofree char *real_file = virtio_9p_test_path("06/real_file"); + g_autofree char *symlink_file = virtio_9p_test_path("06/symlink_file"); do_attach(v9p); do_mkdir(v9p, "/", "06"); @@ -1364,9 +1337,6 @@ static void fs_unlinkat_symlink(void *obj, void *data, do_unlinkat(v9p, "06", "symlink_file", 0); /* symlink should be gone now */ g_assert(stat(symlink_file, &st) != 0); - - g_free(symlink_file); - g_free(real_file); } static void fs_hardlink_file(void *obj, void *data, QGuestAllocator *t_alloc) @@ -1374,8 +1344,8 @@ static void fs_hardlink_file(void *obj, void *data, QGuestAllocator *t_alloc) QVirtio9P *v9p = obj; alloc = t_alloc; struct stat st_real, st_link; - char *real_file = virtio_9p_test_path("07/real_file"); - char *hardlink_file = virtio_9p_test_path("07/hardlink_file"); + g_autofree char *real_file = virtio_9p_test_path("07/real_file"); + g_autofree char *hardlink_file = virtio_9p_test_path("07/hardlink_file"); do_attach(v9p); do_mkdir(v9p, "/", "07"); @@ -1391,9 +1361,6 @@ static void fs_hardlink_file(void *obj, void *data, QGuestAllocator *t_alloc) g_assert((st_link.st_mode & S_IFMT) == S_IFREG); g_assert(st_link.st_dev == st_real.st_dev); g_assert(st_link.st_ino == st_real.st_ino); - - g_free(hardlink_file); - g_free(real_file); } static void fs_unlinkat_hardlink(void *obj, void *data, @@ -1402,8 +1369,8 @@ static void fs_unlinkat_hardlink(void *obj, void *data, QVirtio9P *v9p = obj; alloc = t_alloc; struct stat st_real, st_link; - char *real_file = virtio_9p_test_path("08/real_file"); - char *hardlink_file = virtio_9p_test_path("08/hardlink_file"); + g_autofree char *real_file = virtio_9p_test_path("08/real_file"); + g_autofree char *hardlink_file = virtio_9p_test_path("08/hardlink_file"); do_attach(v9p); do_mkdir(v9p, "/", "08"); @@ -1419,9 +1386,6 @@ static void fs_unlinkat_hardlink(void *obj, void *data, g_assert(stat(hardlink_file, &st_link) != 0); /* and old file should still exist */ g_assert(stat(real_file, &st_real) == 0); - - g_free(hardlink_file); - g_free(real_file); } static void *assign_9p_local_driver(GString *cmd_line, void *arg) -- 2.20.1 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PULL 4/5] tests/9pfs: Use g_autofree and g_autoptr where possible 2022-02-10 11:21 [PULL 0/5] 9p queue 2022-02-10 Christian Schoenebeck ` (3 preceding siblings ...) 2022-02-10 11:21 ` [PULL 1/5] tests/9pfs: use g_autofree where possible Christian Schoenebeck @ 2022-02-10 11:21 ` Christian Schoenebeck 2022-02-13 20:33 ` [PULL 0/5] 9p queue 2022-02-10 Peter Maydell 5 siblings, 0 replies; 20+ messages in thread From: Christian Schoenebeck @ 2022-02-10 11:21 UTC (permalink / raw) To: qemu-devel, Peter Maydell; +Cc: Greg Kurz From: Greg Kurz <groug@kaod.org> It is recommended to use g_autofree or g_autoptr as it reduces the odds of introducing memory leaks in future changes. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <20220201151508.190035-3-groug@kaod.org> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> --- tests/qtest/libqos/virtio-9p.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/tests/qtest/libqos/virtio-9p.c b/tests/qtest/libqos/virtio-9p.c index 5d18e5eae5..f51f0635cc 100644 --- a/tests/qtest/libqos/virtio-9p.c +++ b/tests/qtest/libqos/virtio-9p.c @@ -41,7 +41,7 @@ void virtio_9p_create_local_test_dir(void) { g_assert(local_test_path == NULL); struct stat st; - char *pwd = g_get_current_dir(); + g_autofree char *pwd = g_get_current_dir(); /* * template gets cached into local_test_path and freed in * virtio_9p_remove_local_test_dir(). @@ -52,7 +52,6 @@ void virtio_9p_create_local_test_dir(void) if (!local_test_path) { g_test_message("mkdtemp('%s') failed: %s", template, strerror(errno)); } - g_free(pwd); g_assert(local_test_path != NULL); @@ -65,12 +64,11 @@ void virtio_9p_create_local_test_dir(void) void virtio_9p_remove_local_test_dir(void) { g_assert(local_test_path != NULL); - char *cmd = g_strdup_printf("rm -fr '%s'\n", local_test_path); + g_autofree char *cmd = g_strdup_printf("rm -fr '%s'\n", local_test_path); int res = system(cmd); if (res < 0) { /* ignore error, dummy check to prevent compiler error */ } - g_free(cmd); g_free(local_test_path); local_test_path = NULL; } @@ -216,8 +214,8 @@ static void *virtio_9p_pci_create(void *pci_bus, QGuestAllocator *t_alloc, static void regex_replace(GString *haystack, const char *pattern, const char *replace_fmt, ...) { - GRegex *regex; - char *replace, *s; + g_autoptr(GRegex) regex = NULL; + g_autofree char *replace = NULL, *s = NULL; va_list argp; va_start(argp, replace_fmt); @@ -227,9 +225,6 @@ static void regex_replace(GString *haystack, const char *pattern, regex = g_regex_new(pattern, 0, 0, NULL); s = g_regex_replace(regex, haystack->str, -1, 0, replace, 0, NULL); g_string_assign(haystack, s); - g_free(s); - g_regex_unref(regex); - g_free(replace); } void virtio_9p_assign_local_driver(GString *cmd_line, const char *args) -- 2.20.1 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PULL 0/5] 9p queue 2022-02-10 2022-02-10 11:21 [PULL 0/5] 9p queue 2022-02-10 Christian Schoenebeck ` (4 preceding siblings ...) 2022-02-10 11:21 ` [PULL 4/5] tests/9pfs: Use g_autofree and g_autoptr " Christian Schoenebeck @ 2022-02-13 20:33 ` Peter Maydell 2022-02-14 9:47 ` Christian Schoenebeck 5 siblings, 1 reply; 20+ messages in thread From: Peter Maydell @ 2022-02-13 20:33 UTC (permalink / raw) To: Christian Schoenebeck; +Cc: qemu-devel, Greg Kurz On Thu, 10 Feb 2022 at 11:33, Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > > The following changes since commit 0a301624c2f4ced3331ffd5bce85b4274fe132af: > > Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20220208' into staging (2022-02-08 11:40:08 +0000) > > are available in the Git repository at: > > https://github.com/cschoenebeck/qemu.git tags/pull-9p-20220210 > > for you to fetch changes up to de19c79dad6a2cad54ae04ce754d47c07bf9bc93: > > 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread (2022-02-10 11:56:01 +0100) > > ---------------------------------------------------------------- > 9pfs: fixes and cleanup > > * Fifth patch fixes a 9pfs server crash that happened on some systems due > to incorrect (system dependant) handling of struct dirent size. > > * Tests: Second patch fixes a test error that happened on some systems due > mkdir() being called twice for creating the test directory for the 9p > 'local' tests. > > * Tests: Third patch fixes a memory leak. > > * Tests: The remaining two patches are code cleanup. > > ---------------------------------------------------------------- Hi; this fails CI for the build-oss-fuzz job, which finds a heap-buffer-overflow: https://gitlab.com/qemu-project/qemu/-/jobs/2087610013 8/152 qemu:qtest+qtest-i386 / qtest-i386/qos-test ERROR 66.74s killed by signal 6 SIGABRT >>> QTEST_QEMU_BINARY=./qemu-system-i386 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon MALLOC_PERTURB_=120 G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img /builds/qemu-project/qemu/build-oss-fuzz/tests/qtest/qos-test --tap -k ――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― Listing only the last 100 lines from a long log. For details see https://github.com/google/sanitizers/issues/189 ==7270==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! ==7270==WARNING: ASan is ignoring requested __asan_handle_no_return: stack type: default top: 0x7ffc79fb0000; bottom 0x7ff908ffd000; size: 0x000370fb3000 (14780411904) False positive error reports may follow For details see https://github.com/google/sanitizers/issues/189 ==7276==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! ==7276==WARNING: ASan is ignoring requested __asan_handle_no_return: stack type: default top: 0x7fff7e4a8000; bottom 0x7fd6363fd000; size: 0x0029480ab000 (177302319104) False positive error reports may follow For details see https://github.com/google/sanitizers/issues/189 ==7282==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! ==7282==WARNING: ASan is ignoring requested __asan_handle_no_return: stack type: default top: 0x7ffee6e7f000; bottom 0x7f32fb5fd000; size: 0x00cbeb882000 (875829927936) False positive error reports may follow For details see https://github.com/google/sanitizers/issues/189 ==7288==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! ==7288==WARNING: ASan is ignoring requested __asan_handle_no_return: stack type: default top: 0x7ffc6118e000; bottom 0x7f6391cfd000; size: 0x0098cf491000 (656312700928) False positive error reports may follow For details see https://github.com/google/sanitizers/issues/189 ==7294==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! ==7294==WARNING: ASan is ignoring requested __asan_handle_no_return: stack type: default top: 0x7ffef665d000; bottom 0x7f69dc8fd000; size: 0x009519d60000 (640383582208) False positive error reports may follow For details see https://github.com/google/sanitizers/issues/189 ==7300==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! ==7300==WARNING: ASan is ignoring requested __asan_handle_no_return: stack type: default top: 0x7ffe33db0000; bottom 0x7f01421fd000; size: 0x00fcf1bb3000 (1086387335168) False positive error reports may follow For details see https://github.com/google/sanitizers/issues/189 ==7306==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! ==7306==WARNING: ASan is ignoring requested __asan_handle_no_return: stack type: default top: 0x7ffebd618000; bottom 0x7ff1179fd000; size: 0x000da5c1b000 (58615508992) False positive error reports may follow For details see https://github.com/google/sanitizers/issues/189 ================================================================= ==7306==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x612000030768 at pc 0x562351066c74 bp 0x7ff1078c3a90 sp 0x7ff1078c3240 READ of size 48830 at 0x612000030768 thread T4 #0 0x562351066c73 in __interceptor_memcpy.part.0 asan_interceptors.cpp.o #1 0x7ff1290d443f in g_memdup (/lib64/libglib-2.0.so.0+0x6e43f) #2 0x56235134537a in do_readdir_many /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/codir.c:146:19 #3 0x56235134537a in v9fs_co_readdir_many /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/codir.c:225:5 #4 0x56235132d626 in v9fs_do_readdir /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p.c:2430:13 #5 0x56235132d626 in v9fs_readdir /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p.c:2543:13 #6 0x56235257101e in coroutine_trampoline /builds/qemu-project/qemu/build-oss-fuzz/../util/coroutine-ucontext.c:173:9 #7 0x7ff126e0e84f (/lib64/libc.so.6+0x5784f) 0x612000030768 is located 0 bytes to the right of 296-byte region [0x612000030640,0x612000030768) allocated by thread T4 here: #0 0x5623510a4e47 in malloc (/builds/qemu-project/qemu/build-oss-fuzz/qemu-system-i386+0x1146e47) #1 0x7ff1290c03d8 in g_malloc (/lib64/libglib-2.0.so.0+0x5a3d8) #2 0x56235131e659 in synth_opendir /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p-synth.c:185:18 #3 0x5623513462f5 in v9fs_co_opendir /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/codir.c:321:5 #4 0x5623513257d7 in v9fs_open /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p.c:1959:15 #5 0x56235257101e in coroutine_trampoline /builds/qemu-project/qemu/build-oss-fuzz/../util/coroutine-ucontext.c:173:9 #6 0x7ff126e0e84f (/lib64/libc.so.6+0x5784f) Thread T4 created by T0 here: #0 0x562351015926 in pthread_create (/builds/qemu-project/qemu/build-oss-fuzz/qemu-system-i386+0x10b7926) #1 0x5623525351ea in qemu_thread_create /builds/qemu-project/qemu/build-oss-fuzz/../util/qemu-thread-posix.c:596:11 #2 0x5623525a4588 in do_spawn_thread /builds/qemu-project/qemu/build-oss-fuzz/../util/thread-pool.c:134:5 #3 0x5623525a4588 in spawn_thread_bh_fn /builds/qemu-project/qemu/build-oss-fuzz/../util/thread-pool.c:142:5 #4 0x562352569814 in aio_bh_call /builds/qemu-project/qemu/build-oss-fuzz/../util/async.c:141:5 #5 0x562352569814 in aio_bh_poll /builds/qemu-project/qemu/build-oss-fuzz/../util/async.c:169:13 #6 0x5623525248cc in aio_dispatch /builds/qemu-project/qemu/build-oss-fuzz/../util/aio-posix.c:415:5 #7 0x56235256c34c in aio_ctx_dispatch /builds/qemu-project/qemu/build-oss-fuzz/../util/async.c:311:5 #8 0x7ff1290bb05e in g_main_context_dispatch (/lib64/libglib-2.0.so.0+0x5505e) SUMMARY: AddressSanitizer: heap-buffer-overflow asan_interceptors.cpp.o in __interceptor_memcpy.part.0 Shadow bytes around the buggy address: 0x0c247fffe090: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x0c247fffe0a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c247fffe0b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa 0x0c247fffe0c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x0c247fffe0d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c247fffe0e0: 00 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa fa 0x0c247fffe0f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fffe100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fffe110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fffe120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fffe130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==7306==ABORTING thanks -- PMM ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL 0/5] 9p queue 2022-02-10 2022-02-13 20:33 ` [PULL 0/5] 9p queue 2022-02-10 Peter Maydell @ 2022-02-14 9:47 ` Christian Schoenebeck 2022-02-14 9:55 ` Peter Maydell 2022-02-14 10:36 ` Greg Kurz 0 siblings, 2 replies; 20+ messages in thread From: Christian Schoenebeck @ 2022-02-14 9:47 UTC (permalink / raw) To: qemu-devel; +Cc: Peter Maydell, Greg Kurz, Vitaly Chikunov, Dmitry V . Levin On Sonntag, 13. Februar 2022 21:33:10 CET Peter Maydell wrote: > On Thu, 10 Feb 2022 at 11:33, Christian Schoenebeck > > <qemu_oss@crudebyte.com> wrote: > > The following changes since commit 0a301624c2f4ced3331ffd5bce85b4274fe132af: > > Merge remote-tracking branch > > 'remotes/pmaydell/tags/pull-target-arm-20220208' into staging > > (2022-02-08 11:40:08 +0000)> > > are available in the Git repository at: > > https://github.com/cschoenebeck/qemu.git tags/pull-9p-20220210 > > > > for you to fetch changes up to de19c79dad6a2cad54ae04ce754d47c07bf9bc93: > > 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread > > (2022-02-10 11:56:01 +0100)> > > ---------------------------------------------------------------- > > 9pfs: fixes and cleanup > > > > * Fifth patch fixes a 9pfs server crash that happened on some systems due > > > > to incorrect (system dependant) handling of struct dirent size. > > > > * Tests: Second patch fixes a test error that happened on some systems due > > > > mkdir() being called twice for creating the test directory for the 9p > > 'local' tests. > > > > * Tests: Third patch fixes a memory leak. > > > > * Tests: The remaining two patches are code cleanup. > > > > ---------------------------------------------------------------- > > Hi; this fails CI for the build-oss-fuzz job, which finds > a heap-buffer-overflow: > https://gitlab.com/qemu-project/qemu/-/jobs/2087610013 So this is about the 'dirent' patch: https://github.com/cschoenebeck/qemu/commit/de19c79dad6a2cad54ae04ce754d47c07bf9bc93 In conjunction with the 9p fuzzing tests: https://wiki.qemu.org/Documentation/9p#Fuzzing I first thought it might be a false positive due to the unorthodox handling of dirent duplication by that patch, but from the ASan output below I am not really sure about that. Is there a way to get the content of local variables? Would it be possible that the following issue (g_memdup vs. g_memdup2) might apply here? https://discourse.gnome.org/t/port-your-module-from-g-memdup-to-g-memdup2-now/5538 Best regards, Christian Schoenebeck > > 8/152 qemu:qtest+qtest-i386 / qtest-i386/qos-test ERROR 66.74s killed > by signal 6 SIGABRT > > >>> QTEST_QEMU_BINARY=./qemu-system-i386 > >>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon > >>> MALLOC_PERTURB_=120 > >>> G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon. > >>> sh QTEST_QEMU_IMG=./qemu-img > >>> /builds/qemu-project/qemu/build-oss-fuzz/tests/qtest/qos-test --tap -k > ――――――――――――――――――――――――――――――――――――― ✀ > ――――――――――――――――――――――――――――――――――――― Listing only the last 100 lines from > a long log. > For details see https://github.com/google/sanitizers/issues/189 > ==7270==WARNING: ASan doesn't fully support makecontext/swapcontext > functions and may produce false positives in some cases! > ==7270==WARNING: ASan is ignoring requested __asan_handle_no_return: > stack type: default top: 0x7ffc79fb0000; bottom 0x7ff908ffd000; size: > 0x000370fb3000 (14780411904) > False positive error reports may follow > For details see https://github.com/google/sanitizers/issues/189 > ==7276==WARNING: ASan doesn't fully support makecontext/swapcontext > functions and may produce false positives in some cases! > ==7276==WARNING: ASan is ignoring requested __asan_handle_no_return: > stack type: default top: 0x7fff7e4a8000; bottom 0x7fd6363fd000; size: > 0x0029480ab000 (177302319104) > False positive error reports may follow > For details see https://github.com/google/sanitizers/issues/189 > ==7282==WARNING: ASan doesn't fully support makecontext/swapcontext > functions and may produce false positives in some cases! > ==7282==WARNING: ASan is ignoring requested __asan_handle_no_return: > stack type: default top: 0x7ffee6e7f000; bottom 0x7f32fb5fd000; size: > 0x00cbeb882000 (875829927936) > False positive error reports may follow > For details see https://github.com/google/sanitizers/issues/189 > ==7288==WARNING: ASan doesn't fully support makecontext/swapcontext > functions and may produce false positives in some cases! > ==7288==WARNING: ASan is ignoring requested __asan_handle_no_return: > stack type: default top: 0x7ffc6118e000; bottom 0x7f6391cfd000; size: > 0x0098cf491000 (656312700928) > False positive error reports may follow > For details see https://github.com/google/sanitizers/issues/189 > ==7294==WARNING: ASan doesn't fully support makecontext/swapcontext > functions and may produce false positives in some cases! > ==7294==WARNING: ASan is ignoring requested __asan_handle_no_return: > stack type: default top: 0x7ffef665d000; bottom 0x7f69dc8fd000; size: > 0x009519d60000 (640383582208) > False positive error reports may follow > For details see https://github.com/google/sanitizers/issues/189 > ==7300==WARNING: ASan doesn't fully support makecontext/swapcontext > functions and may produce false positives in some cases! > ==7300==WARNING: ASan is ignoring requested __asan_handle_no_return: > stack type: default top: 0x7ffe33db0000; bottom 0x7f01421fd000; size: > 0x00fcf1bb3000 (1086387335168) > False positive error reports may follow > For details see https://github.com/google/sanitizers/issues/189 > ==7306==WARNING: ASan doesn't fully support makecontext/swapcontext > functions and may produce false positives in some cases! > ==7306==WARNING: ASan is ignoring requested __asan_handle_no_return: > stack type: default top: 0x7ffebd618000; bottom 0x7ff1179fd000; size: > 0x000da5c1b000 (58615508992) > False positive error reports may follow > For details see https://github.com/google/sanitizers/issues/189 > ================================================================= > ==7306==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0x612000030768 at pc 0x562351066c74 bp 0x7ff1078c3a90 sp > 0x7ff1078c3240 > READ of size 48830 at 0x612000030768 thread T4 > #0 0x562351066c73 in __interceptor_memcpy.part.0 asan_interceptors.cpp.o > #1 0x7ff1290d443f in g_memdup (/lib64/libglib-2.0.so.0+0x6e43f) > #2 0x56235134537a in do_readdir_many > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/codir.c:146:19 > #3 0x56235134537a in v9fs_co_readdir_many > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/codir.c:225:5 > #4 0x56235132d626 in v9fs_do_readdir > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p.c:2430:13 > #5 0x56235132d626 in v9fs_readdir > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p.c:2543:13 > #6 0x56235257101e in coroutine_trampoline > /builds/qemu-project/qemu/build-oss-fuzz/../util/coroutine-ucontext.c:173:9 > #7 0x7ff126e0e84f (/lib64/libc.so.6+0x5784f) > 0x612000030768 is located 0 bytes to the right of 296-byte region > [0x612000030640,0x612000030768) > allocated by thread T4 here: > #0 0x5623510a4e47 in malloc > (/builds/qemu-project/qemu/build-oss-fuzz/qemu-system-i386+0x1146e47) > #1 0x7ff1290c03d8 in g_malloc (/lib64/libglib-2.0.so.0+0x5a3d8) > #2 0x56235131e659 in synth_opendir > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p-synth.c:185:18 > #3 0x5623513462f5 in v9fs_co_opendir > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/codir.c:321:5 > #4 0x5623513257d7 in v9fs_open > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p.c:1959:15 > #5 0x56235257101e in coroutine_trampoline > /builds/qemu-project/qemu/build-oss-fuzz/../util/coroutine-ucontext.c:173:9 > #6 0x7ff126e0e84f (/lib64/libc.so.6+0x5784f) > Thread T4 created by T0 here: > #0 0x562351015926 in pthread_create > (/builds/qemu-project/qemu/build-oss-fuzz/qemu-system-i386+0x10b7926) > #1 0x5623525351ea in qemu_thread_create > /builds/qemu-project/qemu/build-oss-fuzz/../util/qemu-thread-posix.c:596:11 > #2 0x5623525a4588 in do_spawn_thread > /builds/qemu-project/qemu/build-oss-fuzz/../util/thread-pool.c:134:5 > #3 0x5623525a4588 in spawn_thread_bh_fn > /builds/qemu-project/qemu/build-oss-fuzz/../util/thread-pool.c:142:5 > #4 0x562352569814 in aio_bh_call > /builds/qemu-project/qemu/build-oss-fuzz/../util/async.c:141:5 > #5 0x562352569814 in aio_bh_poll > /builds/qemu-project/qemu/build-oss-fuzz/../util/async.c:169:13 > #6 0x5623525248cc in aio_dispatch > /builds/qemu-project/qemu/build-oss-fuzz/../util/aio-posix.c:415:5 > #7 0x56235256c34c in aio_ctx_dispatch > /builds/qemu-project/qemu/build-oss-fuzz/../util/async.c:311:5 > #8 0x7ff1290bb05e in g_main_context_dispatch > (/lib64/libglib-2.0.so.0+0x5505e) SUMMARY: AddressSanitizer: > heap-buffer-overflow > asan_interceptors.cpp.o in __interceptor_memcpy.part.0 > Shadow bytes around the buggy address: > 0x0c247fffe090: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd > 0x0c247fffe0a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c247fffe0b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa > 0x0c247fffe0c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 > 0x0c247fffe0d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > =>0x0c247fffe0e0: 00 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa fa > 0x0c247fffe0f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c247fffe100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c247fffe110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c247fffe120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c247fffe130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > ==7306==ABORTING > > > thanks > -- PMM ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL 0/5] 9p queue 2022-02-10 2022-02-14 9:47 ` Christian Schoenebeck @ 2022-02-14 9:55 ` Peter Maydell 2022-02-14 12:09 ` Christian Schoenebeck 2022-02-14 10:36 ` Greg Kurz 1 sibling, 1 reply; 20+ messages in thread From: Peter Maydell @ 2022-02-14 9:55 UTC (permalink / raw) To: Christian Schoenebeck Cc: Vitaly Chikunov, Dmitry V . Levin, qemu-devel, Greg Kurz On Mon, 14 Feb 2022 at 09:47, Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > So this is about the 'dirent' patch: > https://github.com/cschoenebeck/qemu/commit/de19c79dad6a2cad54ae04ce754d47c07bf9bc93 > > In conjunction with the 9p fuzzing tests: > https://wiki.qemu.org/Documentation/9p#Fuzzing > > I first thought it might be a false positive due to the unorthodox handling of > dirent duplication by that patch, but from the ASan output below I am not > really sure about that. > > Is there a way to get the content of local variables? Yes. You can build locally with the clang sanitizers enabled and then run under gdb and with the appropriate environment variables to tell the sanitizer to abort() on failures. > Would it be possible that the following issue (g_memdup vs. g_memdup2) might > apply here? > https://discourse.gnome.org/t/port-your-module-from-g-memdup-to-g-memdup2-now/5538 It seems unlikely that the problem is that you're allocating more than 4 gigabytes and thus hitting a 64-to-32 truncation. thanks -- PMM ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL 0/5] 9p queue 2022-02-10 2022-02-14 9:55 ` Peter Maydell @ 2022-02-14 12:09 ` Christian Schoenebeck 0 siblings, 0 replies; 20+ messages in thread From: Christian Schoenebeck @ 2022-02-14 12:09 UTC (permalink / raw) To: qemu-devel; +Cc: Peter Maydell, Vitaly Chikunov, Dmitry V . Levin, Greg Kurz On Montag, 14. Februar 2022 10:55:17 CET Peter Maydell wrote: > On Mon, 14 Feb 2022 at 09:47, Christian Schoenebeck > > <qemu_oss@crudebyte.com> wrote: > > So this is about the 'dirent' patch: > > https://github.com/cschoenebeck/qemu/commit/de19c79dad6a2cad54ae04ce754d47 > > c07bf9bc93 > > > > In conjunction with the 9p fuzzing tests: > > https://wiki.qemu.org/Documentation/9p#Fuzzing > > > > I first thought it might be a false positive due to the unorthodox > > handling of dirent duplication by that patch, but from the ASan output > > below I am not really sure about that. > > > > Is there a way to get the content of local variables? > > Yes. You can build locally with the clang sanitizers enabled and then > run under gdb and with the appropriate environment variables to tell the > sanitizer to abort() on failures. Well, it does no longer matter for this particular issue here, but it would be useful if the CI scripts would already dump the local variables to the logs. E.g. because the patch in question was about system dependant variations. Another reason is the random data nature of fuzzing tests. Even though the latter could probably be reproduced with an appropriate seed. Best regards, Christian Schoenebeck ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL 0/5] 9p queue 2022-02-10 2022-02-14 9:47 ` Christian Schoenebeck 2022-02-14 9:55 ` Peter Maydell @ 2022-02-14 10:36 ` Greg Kurz 2022-02-14 11:44 ` Christian Schoenebeck 1 sibling, 1 reply; 20+ messages in thread From: Greg Kurz @ 2022-02-14 10:36 UTC (permalink / raw) To: Christian Schoenebeck Cc: Vitaly Chikunov, Peter Maydell, qemu-devel, Dmitry V . Levin On Mon, 14 Feb 2022 10:47:43 +0100 Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > On Sonntag, 13. Februar 2022 21:33:10 CET Peter Maydell wrote: > > On Thu, 10 Feb 2022 at 11:33, Christian Schoenebeck > > > > <qemu_oss@crudebyte.com> wrote: > > > The following changes since commit 0a301624c2f4ced3331ffd5bce85b4274fe132af: > > > Merge remote-tracking branch > > > 'remotes/pmaydell/tags/pull-target-arm-20220208' into staging > > > (2022-02-08 11:40:08 +0000)> > > > are available in the Git repository at: > > > https://github.com/cschoenebeck/qemu.git tags/pull-9p-20220210 > > > > > > for you to fetch changes up to de19c79dad6a2cad54ae04ce754d47c07bf9bc93: > > > 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread > > > (2022-02-10 11:56:01 +0100)> > > > ----------------------------------------------------------------9d82f6a3e68c2 > > > 9pfs: fixes and cleanup > > > > > > * Fifth patch fixes a 9pfs server crash that happened on some systems due > > > > > > to incorrect (system dependant) handling of struct dirent size. > > > > > > * Tests: Second patch fixes a test error that happened on some systems due > > > > > > mkdir() being called twice for creating the test directory for the 9p > > > 'local' tests. > > > > > > * Tests: Third patch fixes a memory leak. > > > > > > * Tests: The remaining two patches are code cleanup. > > > > > > ---------------------------------------------------------------- > > > > Hi; this fails CI for the build-oss-fuzz job, which finds > > a heap-buffer-overflow: > > https://gitlab.com/qemu-project/qemu/-/jobs/2087610013 > > So this is about the 'dirent' patch: > https://github.com/cschoenebeck/qemu/commit/de19c79dad6a2cad54ae04ce754d47c07bf9bc93 > > In conjunction with the 9p fuzzing tests: > https://wiki.qemu.org/Documentation/9p#Fuzzing > > I first thought it might be a false positive due to the unorthodox handling of > dirent duplication by that patch, but from the ASan output below I am not > really sure about that. > No, this is an actual bug. See below. > Is there a way to get the content of local variables? > > Would it be possible that the following issue (g_memdup vs. g_memdup2) might > apply here? > https://discourse.gnome.org/t/port-your-module-from-g-memdup-to-g-memdup2-now/5538 > > Best regards, > Christian Schoenebeck > > > > > 8/152 qemu:qtest+qtest-i386 / qtest-i386/qos-test ERROR 66.74s killed > > by signal 6 SIGABRT > > > > >>> QTEST_QEMU_BINARY=./qemu-system-i386 > > >>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon > > >>> MALLOC_PERTURB_=120 > > >>> G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon. > > >>> sh QTEST_QEMU_IMG=./qemu-img > > >>> /builds/qemu-project/qemu/build-oss-fuzz/tests/qtest/qos-test --tap -k > > ――――――――――――――――――――――――――――――――――――― ✀ > > ――――――――――――――――――――――――――――――――――――― Listing only the last 100 lines from > > a long log. > > For details see https://github.com/google/sanitizers/issues/189 > > ==7270==WARNING: ASan doesn't fully support makecontext/swapcontext > > functions and may produce false positives in some cases! > > ==7270==WARNING: ASan is ignoring requested __asan_handle_no_return: > > stack type: default top: 0x7ffc79fb0000; bottom 0x7ff908ffd000; size: > > 0x000370fb3000 (14780411904) > > False positive error reports may follow > > For details see https://github.com/google/sanitizers/issues/189 > > ==7276==WARNING: ASan doesn't fully support makecontext/swapcontext > > functions and may produce false positives in some cases! > > ==7276==WARNING: ASan is ignoring requested __asan_handle_no_return: > > stack type: default top: 0x7fff7e4a8000; bottom 0x7fd6363fd000; size: > > 0x0029480ab000 (177302319104) > > False positive error reports may follow > > For details see https://github.com/google/sanitizers/issues/189 > > ==7282==WARNING: ASan doesn't fully support makecontext/swapcontext > > functions and may produce false positives in some cases! > > ==7282==WARNING: ASan is ignoring requested __asan_handle_no_return: > > stack type: default top: 0x7ffee6e7f000; bottom 0x7f32fb5fd000; size: > > 0x00cbeb882000 (875829927936) > > False positive error reports may follow > > For details see https://github.com/google/sanitizers/issues/189 > > ==7288==WARNING: ASan doesn't fully support makecontext/swapcontext > > functions and may produce false positives in some cases! > > ==7288==WARNING: ASan is ignoring requested __asan_handle_no_return: > > stack type: default top: 0x7ffc6118e000; bottom 0x7f6391cfd000; size: > > 0x0098cf491000 (656312700928) > > False positive error reports may follow > > For details see https://github.com/google/sanitizers/issues/189 > > ==7294==WARNING: ASan doesn't fully support makecontext/swapcontext > > functions and may produce false positives in some cases! > > ==7294==WARNING: ASan is ignoring requested __asan_handle_no_return: > > stack type: default top: 0x7ffef665d000; bottom 0x7f69dc8fd000; size: > > 0x009519d60000 (640383582208) > > False positive error reports may follow > > For details see https://github.com/google/sanitizers/issues/189 > > ==7300==WARNING: ASan doesn't fully support makecontext/swapcontext > > functions and may produce false positives in some cases! > > ==7300==WARNING: ASan is ignoring requested __asan_handle_no_return: > > stack type: default top: 0x7ffe33db0000; bottom 0x7f01421fd000; size: > > 0x00fcf1bb3000 (1086387335168) > > False positive error reports may follow > > For details see https://github.com/google/sanitizers/issues/189 > > ==7306==WARNING: ASan doesn't fully support makecontext/swapcontext > > functions and may produce false positives in some cases! > > ==7306==WARNING: ASan is ignoring requested __asan_handle_no_return: > > stack type: default top: 0x7ffebd618000; bottom 0x7ff1179fd000; size: > > 0x000da5c1b000 (58615508992) > > False positive error reports may follow > > For details see https://github.com/google/sanitizers/issues/189 > > ================================================================= > > ==7306==ERROR: AddressSanitizer: heap-buffer-overflow on address > > 0x612000030768 at pc 0x562351066c74 bp 0x7ff1078c3a90 sp > > 0x7ff1078c3240 > > READ of size 48830 at 0x612000030768 thread T4 The size looks pretty big to me. Test file paths in virtio-9p-test are only a couple of bytes long... > > #0 0x562351066c73 in __interceptor_memcpy.part.0 asan_interceptors.cpp.o > > #1 0x7ff1290d443f in g_memdup (/lib64/libglib-2.0.so.0+0x6e43f) > > #2 0x56235134537a in do_readdir_many > > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/codir.c:146:19 > > #3 0x56235134537a in v9fs_co_readdir_many > > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/codir.c:225:5 > > #4 0x56235132d626 in v9fs_do_readdir > > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p.c:2430:13 > > #5 0x56235132d626 in v9fs_readdir > > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p.c:2543:13 > > #6 0x56235257101e in coroutine_trampoline > > /builds/qemu-project/qemu/build-oss-fuzz/../util/coroutine-ucontext.c:173:9 > > #7 0x7ff126e0e84f (/lib64/libc.so.6+0x5784f) > > 0x612000030768 is located 0 bytes to the right of 296-byte region > > [0x612000030640,0x612000030768) > > allocated by thread T4 here: > > #0 0x5623510a4e47 in malloc > > (/builds/qemu-project/qemu/build-oss-fuzz/qemu-system-i386+0x1146e47) > > #1 0x7ff1290c03d8 in g_malloc (/lib64/libglib-2.0.so.0+0x5a3d8) i.e. synth_open = g_malloc(sizeof(*synth_open)); and we have: typedef struct V9fsSynthOpenState { off_t offset; V9fsSynthNode *node; struct dirent dent; } V9fsSynthOpenState; It looks like that qemu_dirent_dup() ends up using an uninitialized dent->d_reclen. The synth backend should be fixed to honor d_reclen, or at least to allocate with g_new0(). Cheers, -- Greg > > #2 0x56235131e659 in synth_opendir > > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p-synth.c:185:18 > > #3 0x5623513462f5 in v9fs_co_opendir > > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/codir.c:321:5 > > #4 0x5623513257d7 in v9fs_open > > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p.c:1959:15 > > #5 0x56235257101e in coroutine_trampoline > > /builds/qemu-project/qemu/build-oss-fuzz/../util/coroutine-ucontext.c:173:9 > > #6 0x7ff126e0e84f (/lib64/libc.so.6+0x5784f) > > Thread T4 created by T0 here: > > #0 0x562351015926 in pthread_create > > (/builds/qemu-project/qemu/build-oss-fuzz/qemu-system-i386+0x10b7926) > > #1 0x5623525351ea in qemu_thread_create > > /builds/qemu-project/qemu/build-oss-fuzz/../util/qemu-thread-posix.c:596:11 > > #2 0x5623525a4588 in do_spawn_thread > > /builds/qemu-project/qemu/build-oss-fuzz/../util/thread-pool.c:134:5 > > #3 0x5623525a4588 in spawn_thread_bh_fn > > /builds/qemu-project/qemu/build-oss-fuzz/../util/thread-pool.c:142:5 > > #4 0x562352569814 in aio_bh_call > > /builds/qemu-project/qemu/build-oss-fuzz/../util/async.c:141:5 > > #5 0x562352569814 in aio_bh_poll > > /builds/qemu-project/qemu/build-oss-fuzz/../util/async.c:169:13 > > #6 0x5623525248cc in aio_dispatch > > /builds/qemu-project/qemu/build-oss-fuzz/../util/aio-posix.c:415:5 > > #7 0x56235256c34c in aio_ctx_dispatch > > /builds/qemu-project/qemu/build-oss-fuzz/../util/async.c:311:5 > > #8 0x7ff1290bb05e in g_main_context_dispatch > > (/lib64/libglib-2.0.so.0+0x5505e) SUMMARY: AddressSanitizer: > > heap-buffer-overflow > > asan_interceptors.cpp.o in __interceptor_memcpy.part.0 > > Shadow bytes around the buggy address: > > 0x0c247fffe090: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd > > 0x0c247fffe0a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > > 0x0c247fffe0b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa > > 0x0c247fffe0c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 > > 0x0c247fffe0d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > =>0x0c247fffe0e0: 00 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa fa > > 0x0c247fffe0f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > 0x0c247fffe100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > 0x0c247fffe110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > 0x0c247fffe120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > 0x0c247fffe130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > Shadow byte legend (one shadow byte represents 8 application bytes): > > Addressable: 00 > > Partially addressable: 01 02 03 04 05 06 07 > > Heap left redzone: fa > > Freed heap region: fd > > Stack left redzone: f1 > > Stack mid redzone: f2 > > Stack right redzone: f3 > > Stack after return: f5 > > Stack use after scope: f8 > > Global redzone: f9 > > Global init order: f6 > > Poisoned by user: f7 > > Container overflow: fc > > Array cookie: ac > > Intra object redzone: bb > > ASan internal: fe > > Left alloca redzone: ca > > Right alloca redzone: cb > > ==7306==ABORTING > > > > > > thanks > > -- PMM > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL 0/5] 9p queue 2022-02-10 2022-02-14 10:36 ` Greg Kurz @ 2022-02-14 11:44 ` Christian Schoenebeck 2022-02-14 14:43 ` Vitaly Chikunov 0 siblings, 1 reply; 20+ messages in thread From: Christian Schoenebeck @ 2022-02-14 11:44 UTC (permalink / raw) To: qemu-devel; +Cc: Greg Kurz, Vitaly Chikunov, Peter Maydell, Dmitry V . Levin On Montag, 14. Februar 2022 11:36:53 CET Greg Kurz wrote: > On Mon, 14 Feb 2022 10:47:43 +0100 > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > > On Sonntag, 13. Februar 2022 21:33:10 CET Peter Maydell wrote: > > > On Thu, 10 Feb 2022 at 11:33, Christian Schoenebeck > > > > > > <qemu_oss@crudebyte.com> wrote: > > > > The following changes since commit 0a301624c2f4ced3331ffd5bce85b4274fe132af: > > > > Merge remote-tracking branch > > > > 'remotes/pmaydell/tags/pull-target-arm-20220208' into staging > > > > (2022-02-08 11:40:08 +0000)> > > > > > > > > are available in the Git repository at: > > > > https://github.com/cschoenebeck/qemu.git tags/pull-9p-20220210 > > > > > > > > for you to fetch changes up to de19c79dad6a2cad54ae04ce754d47c07bf9bc93: > > > > 9pfs: Fix segfault in do_readdir_many caused by struct dirent > > > > overread > > > > (2022-02-10 11:56:01 +0100)> > > > > > > > > ----------------------------------------------------------------9d82f6 > > > > a3e68c2 9pfs: fixes and cleanup > > > > > > > > * Fifth patch fixes a 9pfs server crash that happened on some systems > > > > due > > > > > > > > to incorrect (system dependant) handling of struct dirent size. > > > > > > > > * Tests: Second patch fixes a test error that happened on some systems > > > > due > > > > > > > > mkdir() being called twice for creating the test directory for the > > > > 9p > > > > 'local' tests. > > > > > > > > * Tests: Third patch fixes a memory leak. > > > > > > > > * Tests: The remaining two patches are code cleanup. > > > > > > > > ---------------------------------------------------------------- > > > > > > Hi; this fails CI for the build-oss-fuzz job, which finds > > > a heap-buffer-overflow: > > > https://gitlab.com/qemu-project/qemu/-/jobs/2087610013 > > > > So this is about the 'dirent' patch: > > https://github.com/cschoenebeck/qemu/commit/de19c79dad6a2cad54ae04ce754d47 > > c07bf9bc93 > > > > In conjunction with the 9p fuzzing tests: > > https://wiki.qemu.org/Documentation/9p#Fuzzing > > > > I first thought it might be a false positive due to the unorthodox > > handling of dirent duplication by that patch, but from the ASan output > > below I am not really sure about that. > > No, this is an actual bug. See below. Yep, the patch would turn the 9p tests' synth driver buggy. :/ Vitaly, I fear the patch needs a v5. > > Is there a way to get the content of local variables? > > > > Would it be possible that the following issue (g_memdup vs. g_memdup2) > > might apply here? > > https://discourse.gnome.org/t/port-your-module-from-g-memdup-to-g-memdup2-> > now/5538 > > > > Best regards, > > Christian Schoenebeck > > > > > 8/152 qemu:qtest+qtest-i386 / qtest-i386/qos-test ERROR 66.74s killed > > > by signal 6 SIGABRT > > > > > > >>> QTEST_QEMU_BINARY=./qemu-system-i386 > > > >>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemo > > > >>> n > > > >>> MALLOC_PERTURB_=120 > > > >>> G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daem > > > >>> on. > > > >>> sh QTEST_QEMU_IMG=./qemu-img > > > >>> /builds/qemu-project/qemu/build-oss-fuzz/tests/qtest/qos-test --tap > > > >>> -k > > > > > > ――――――――――――――――――――――――――――――――――――― ✀ > > > ――――――――――――――――――――――――――――――――――――― Listing only the last 100 lines > > > from > > > a long log. > > > For details see https://github.com/google/sanitizers/issues/189 > > > ==7270==WARNING: ASan doesn't fully support makecontext/swapcontext > > > functions and may produce false positives in some cases! > > > ==7270==WARNING: ASan is ignoring requested __asan_handle_no_return: > > > stack type: default top: 0x7ffc79fb0000; bottom 0x7ff908ffd000; size: > > > 0x000370fb3000 (14780411904) > > > False positive error reports may follow > > > For details see https://github.com/google/sanitizers/issues/189 > > > ==7276==WARNING: ASan doesn't fully support makecontext/swapcontext > > > functions and may produce false positives in some cases! > > > ==7276==WARNING: ASan is ignoring requested __asan_handle_no_return: > > > stack type: default top: 0x7fff7e4a8000; bottom 0x7fd6363fd000; size: > > > 0x0029480ab000 (177302319104) > > > False positive error reports may follow > > > For details see https://github.com/google/sanitizers/issues/189 > > > ==7282==WARNING: ASan doesn't fully support makecontext/swapcontext > > > functions and may produce false positives in some cases! > > > ==7282==WARNING: ASan is ignoring requested __asan_handle_no_return: > > > stack type: default top: 0x7ffee6e7f000; bottom 0x7f32fb5fd000; size: > > > 0x00cbeb882000 (875829927936) > > > False positive error reports may follow > > > For details see https://github.com/google/sanitizers/issues/189 > > > ==7288==WARNING: ASan doesn't fully support makecontext/swapcontext > > > functions and may produce false positives in some cases! > > > ==7288==WARNING: ASan is ignoring requested __asan_handle_no_return: > > > stack type: default top: 0x7ffc6118e000; bottom 0x7f6391cfd000; size: > > > 0x0098cf491000 (656312700928) > > > False positive error reports may follow > > > For details see https://github.com/google/sanitizers/issues/189 > > > ==7294==WARNING: ASan doesn't fully support makecontext/swapcontext > > > functions and may produce false positives in some cases! > > > ==7294==WARNING: ASan is ignoring requested __asan_handle_no_return: > > > stack type: default top: 0x7ffef665d000; bottom 0x7f69dc8fd000; size: > > > 0x009519d60000 (640383582208) > > > False positive error reports may follow > > > For details see https://github.com/google/sanitizers/issues/189 > > > ==7300==WARNING: ASan doesn't fully support makecontext/swapcontext > > > functions and may produce false positives in some cases! > > > ==7300==WARNING: ASan is ignoring requested __asan_handle_no_return: > > > stack type: default top: 0x7ffe33db0000; bottom 0x7f01421fd000; size: > > > 0x00fcf1bb3000 (1086387335168) > > > False positive error reports may follow > > > For details see https://github.com/google/sanitizers/issues/189 > > > ==7306==WARNING: ASan doesn't fully support makecontext/swapcontext > > > functions and may produce false positives in some cases! > > > ==7306==WARNING: ASan is ignoring requested __asan_handle_no_return: > > > stack type: default top: 0x7ffebd618000; bottom 0x7ff1179fd000; size: > > > 0x000da5c1b000 (58615508992) > > > False positive error reports may follow > > > For details see https://github.com/google/sanitizers/issues/189 > > > ================================================================= > > > ==7306==ERROR: AddressSanitizer: heap-buffer-overflow on address > > > 0x612000030768 at pc 0x562351066c74 bp 0x7ff1078c3a90 sp > > > 0x7ff1078c3240 > > > READ of size 48830 at 0x612000030768 thread T4 > > The size looks pretty big to me. Test file paths in virtio-9p-test are > only a couple of bytes long... Right. > > > #0 0x562351066c73 in __interceptor_memcpy.part.0 asan_interceptors.cpp.o > > > #1 0x7ff1290d443f in g_memdup (/lib64/libglib-2.0.so.0+0x6e43f) > > > #2 0x56235134537a in do_readdir_many > > > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/codir.c:146:19 > > > #3 0x56235134537a in v9fs_co_readdir_many > > > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/codir.c:225:5 > > > #4 0x56235132d626 in v9fs_do_readdir > > > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p.c:2430:13 > > > #5 0x56235132d626 in v9fs_readdir > > > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p.c:2543:13 > > > #6 0x56235257101e in coroutine_trampoline > > > /builds/qemu-project/qemu/build-oss-fuzz/../util/coroutine-ucontext.c:17 > > > 3:9 > > > #7 0x7ff126e0e84f (/lib64/libc.so.6+0x5784f) > > > 0x612000030768 is located 0 bytes to the right of 296-byte region > > > [0x612000030640,0x612000030768) > > > allocated by thread T4 here: > > > #0 0x5623510a4e47 in malloc > > > (/builds/qemu-project/qemu/build-oss-fuzz/qemu-system-i386+0x1146e47) > > > #1 0x7ff1290c03d8 in g_malloc (/lib64/libglib-2.0.so.0+0x5a3d8) > > i.e. > > synth_open = g_malloc(sizeof(*synth_open)); > > and we have: > > typedef struct V9fsSynthOpenState { > off_t offset; > V9fsSynthNode *node; > struct dirent dent; > } V9fsSynthOpenState; > > It looks like that qemu_dirent_dup() ends up using an > uninitialized dent->d_reclen. > > The synth backend should be fixed to honor d_reclen, or > at least to allocate with g_new0(). Yes, I overlooked that this is not initialized with zero already. With g_new0() d_reclen would be zero and qemu_dirent_dup() would then fallback to the portable branch (as I assumed it already would): struct dirent * qemu_dirent_dup(struct dirent *dent) { size_t sz = 0; #if defined _DIRENT_HAVE_D_RECLEN /* Avoid use of strlen() if platform supports d_reclen. */ sz = dent->d_reclen; #endif /* * Test sz for zero even if d_reclen is available * because some drivers may set d_reclen to zero. */ if (sz == 0) { /* Fallback to the most portable way. */ sz = offsetof(struct dirent, d_name) + strlen(dent->d_name) + 1; } return g_memdup(dent, sz); } Additionally I would add NAME_MAX to the V9fsSynthOpenState allocation size, because it is known that some systems define dirent as flex-array (zero d_name size). I know Greg would not favour this solution (using g_new0), but it's the most minimalistic and most portable solution. So I would favour it for now. A cleaner solution on the long-term would be turning V9fsSynthOpenState's 'dent' member into a pointer and adding a new function to osdep like: struct dirent * qemu_dirent_new(const char* name) { ... } But I would like to postpone that qemu_dirent_new() solution, e.g. because I guess some people would probably not like qemu_dirent_new() to have in osdep, as it is probably not a general purpose function, and I am not keen putting qemu_dirent_new() into a different location than qemu_dirent_dup(), because it would raise the danger that system dependent code might deviate in future. Best regards, Christian Schoenebeck > > Cheers, > > -- > Greg > > > > #2 0x56235131e659 in synth_opendir > > > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p-synth.c:185:18 > > > #3 0x5623513462f5 in v9fs_co_opendir > > > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/codir.c:321:5 > > > #4 0x5623513257d7 in v9fs_open > > > /builds/qemu-project/qemu/build-oss-fuzz/../hw/9pfs/9p.c:1959:15 > > > #5 0x56235257101e in coroutine_trampoline > > > /builds/qemu-project/qemu/build-oss-fuzz/../util/coroutine-ucontext.c:17 > > > 3:9 > > > #6 0x7ff126e0e84f (/lib64/libc.so.6+0x5784f) > > > Thread T4 created by T0 here: > > > #0 0x562351015926 in pthread_create > > > (/builds/qemu-project/qemu/build-oss-fuzz/qemu-system-i386+0x10b7926) > > > #1 0x5623525351ea in qemu_thread_create > > > /builds/qemu-project/qemu/build-oss-fuzz/../util/qemu-thread-posix.c:596 > > > :11 > > > #2 0x5623525a4588 in do_spawn_thread > > > /builds/qemu-project/qemu/build-oss-fuzz/../util/thread-pool.c:134:5 > > > #3 0x5623525a4588 in spawn_thread_bh_fn > > > /builds/qemu-project/qemu/build-oss-fuzz/../util/thread-pool.c:142:5 > > > #4 0x562352569814 in aio_bh_call > > > /builds/qemu-project/qemu/build-oss-fuzz/../util/async.c:141:5 > > > #5 0x562352569814 in aio_bh_poll > > > /builds/qemu-project/qemu/build-oss-fuzz/../util/async.c:169:13 > > > #6 0x5623525248cc in aio_dispatch > > > /builds/qemu-project/qemu/build-oss-fuzz/../util/aio-posix.c:415:5 > > > #7 0x56235256c34c in aio_ctx_dispatch > > > /builds/qemu-project/qemu/build-oss-fuzz/../util/async.c:311:5 > > > #8 0x7ff1290bb05e in g_main_context_dispatch > > > (/lib64/libglib-2.0.so.0+0x5505e) SUMMARY: AddressSanitizer: > > > heap-buffer-overflow > > > asan_interceptors.cpp.o in __interceptor_memcpy.part.0 > > > Shadow bytes around the buggy address: > > > 0x0c247fffe090: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd > > > 0x0c247fffe0a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > > > 0x0c247fffe0b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa > > > 0x0c247fffe0c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 > > > 0x0c247fffe0d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > =>0x0c247fffe0e0: 00 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa fa > > > 0x0c247fffe0f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > > 0x0c247fffe100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > > 0x0c247fffe110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > > 0x0c247fffe120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > > 0x0c247fffe130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > > Shadow byte legend (one shadow byte represents 8 application bytes): > > > Addressable: 00 > > > Partially addressable: 01 02 03 04 05 06 07 > > > Heap left redzone: fa > > > Freed heap region: fd > > > Stack left redzone: f1 > > > Stack mid redzone: f2 > > > Stack right redzone: f3 > > > Stack after return: f5 > > > Stack use after scope: f8 > > > Global redzone: f9 > > > Global init order: f6 > > > Poisoned by user: f7 > > > Container overflow: fc > > > Array cookie: ac > > > Intra object redzone: bb > > > ASan internal: fe > > > Left alloca redzone: ca > > > Right alloca redzone: cb > > > ==7306==ABORTING > > > > > > > > > thanks > > > -- PMM ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL 0/5] 9p queue 2022-02-10 2022-02-14 11:44 ` Christian Schoenebeck @ 2022-02-14 14:43 ` Vitaly Chikunov 2022-02-14 17:40 ` Christian Schoenebeck 2022-02-15 7:01 ` Greg Kurz 0 siblings, 2 replies; 20+ messages in thread From: Vitaly Chikunov @ 2022-02-14 14:43 UTC (permalink / raw) To: Christian Schoenebeck Cc: Peter Maydell, Dmitry V . Levin, qemu-devel, Greg Kurz Christian, On Mon, Feb 14, 2022 at 12:44:48PM +0100, Christian Schoenebeck wrote: > On Montag, 14. Februar 2022 11:36:53 CET Greg Kurz wrote: > > The synth backend should be fixed to honor d_reclen, or > > at least to allocate with g_new0(). > > Yes, I overlooked that this is not initialized with zero already. > > With g_new0() d_reclen would be zero and qemu_dirent_dup() would then fallback > to the portable branch (as I assumed it already would): Perhaps, this additional change should be added (I only found two instances of V9fsSynthOpenState allocation): diff --git a/hw/9pfs/9p-synth.c b/hw/9pfs/9p-synth.c --- a/hw/9pfs/9p-synth.c +++ b/hw/9pfs/9p-synth.c @@ -182,7 +182,7 @@ static int synth_opendir(FsContext *ctx, V9fsSynthOpenState *synth_open; V9fsSynthNode *node = *(V9fsSynthNode **)fs_path->data; - synth_open = g_malloc(sizeof(*synth_open)); + synth_open = g_malloc0(sizeof(*synth_open)); synth_open->node = node; node->open_count++; fs->private = synth_open; @@ -266,7 +266,7 @@ static int synth_open(FsContext *ctx, V9fsPath *fs_path, V9fsSynthOpenState *synth_open; V9fsSynthNode *node = *(V9fsSynthNode **)fs_path->data; - synth_open = g_malloc(sizeof(*synth_open)); + synth_open = g_malloc0(sizeof(*synth_open)); synth_open->node = node; node->open_count++; fs->private = synth_open; > Additionally I would add NAME_MAX to the V9fsSynthOpenState allocation size, > because it is known that some systems define dirent as flex-array (zero d_name > size). (To be precise) not just zero, but 1 byte. Also, to remind, for some filesystems, such as CIFS, actual d_name size could be longer than NAME_MAX. Because of that struct dirent cannot be allocated statically or with simple sizeof. > > I know Greg would not favour this solution (using g_new0), but it's the most > minimalistic and most portable solution. So I would favour it for now. Why g_new0 and not just g_malloc0? This is smallest code change, which seems appropriate for a bug fix. Thanks, > > A cleaner solution on the long-term would be turning V9fsSynthOpenState's > 'dent' member into a pointer and adding a new function to osdep like: > > struct dirent * > qemu_dirent_new(const char* name) { > ... > } > > But I would like to postpone that qemu_dirent_new() solution, e.g. because I > guess some people would probably not like qemu_dirent_new() to have in osdep, > as it is probably not a general purpose function, and I am not keen putting > qemu_dirent_new() into a different location than qemu_dirent_dup(), because it > would raise the danger that system dependent code might deviate in future. > > Best regards, > Christian Schoenebeck > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL 0/5] 9p queue 2022-02-10 2022-02-14 14:43 ` Vitaly Chikunov @ 2022-02-14 17:40 ` Christian Schoenebeck 2022-02-15 7:01 ` Greg Kurz 1 sibling, 0 replies; 20+ messages in thread From: Christian Schoenebeck @ 2022-02-14 17:40 UTC (permalink / raw) To: qemu-devel; +Cc: Vitaly Chikunov, Peter Maydell, Dmitry V . Levin, Greg Kurz On Montag, 14. Februar 2022 15:43:51 CET Vitaly Chikunov wrote: > Christian, > > On Mon, Feb 14, 2022 at 12:44:48PM +0100, Christian Schoenebeck wrote: > > On Montag, 14. Februar 2022 11:36:53 CET Greg Kurz wrote: > > > The synth backend should be fixed to honor d_reclen, or > > > at least to allocate with g_new0(). > > > > Yes, I overlooked that this is not initialized with zero already. > > > > With g_new0() d_reclen would be zero and qemu_dirent_dup() would then > > fallback > > to the portable branch (as I assumed it already would): > Perhaps, this additional change should be added (I only found two instances > of V9fsSynthOpenState allocation): > > diff --git a/hw/9pfs/9p-synth.c b/hw/9pfs/9p-synth.c > --- a/hw/9pfs/9p-synth.c > +++ b/hw/9pfs/9p-synth.c > @@ -182,7 +182,7 @@ static int synth_opendir(FsContext *ctx, > V9fsSynthOpenState *synth_open; > V9fsSynthNode *node = *(V9fsSynthNode **)fs_path->data; > > - synth_open = g_malloc(sizeof(*synth_open)); > + synth_open = g_malloc0(sizeof(*synth_open)); > synth_open->node = node; > node->open_count++; > fs->private = synth_open; > @@ -266,7 +266,7 @@ static int synth_open(FsContext *ctx, V9fsPath *fs_path, > V9fsSynthOpenState *synth_open; > V9fsSynthNode *node = *(V9fsSynthNode **)fs_path->data; > > - synth_open = g_malloc(sizeof(*synth_open)); > + synth_open = g_malloc0(sizeof(*synth_open)); > synth_open->node = node; > node->open_count++; > fs->private = synth_open; Either /* * Add NAME_MAX to ensure there is enough space for 'dent' member, because * some systems have d_name size of just 1, which would cause a buffer * overrun. */ synth_open = g_malloc0(sizeof(*synth_open) + NAME_MAX); Or more simple by adjusting struct V9fsSynthOpenState: index 036d7e4a5b..eeb246f377 100644 --- a/hw/9pfs/9p-synth.h +++ b/hw/9pfs/9p-synth.h @@ -41,6 +41,11 @@ typedef struct V9fsSynthOpenState { off_t offset; V9fsSynthNode *node; struct dirent dent; + /* + * Ensure there is enough space for 'dent' above, some systems have a + * d_name size of just 1, which would cause a buffer overrun. + */ + char dent_trailing_space[NAME_MAX]; } V9fsSynthOpenState; int qemu_v9fs_synth_mkdir(V9fsSynthNode *parent, int mode, and of course still replacing g_malloc() by g_malloc0(). > > Additionally I would add NAME_MAX to the V9fsSynthOpenState allocation > > size, because it is known that some systems define dirent as flex-array > > (zero d_name size). > > (To be precise) not just zero, but 1 byte. Also, to remind, for some > filesystems, such as CIFS, actual d_name size could be longer than NAME_MAX. > Because of that struct dirent cannot be allocated statically or with simple > sizeof. Yes, but the dir names in the synth driver are just short hard coded names anyway, there is no access to a real filesystem going on in the synth driver. > > I know Greg would not favour this solution (using g_new0), but it's the > > most minimalistic and most portable solution. So I would favour it for > > now. > Why g_new0 and not just g_malloc0? This is smallest code change, which seems > appropriate for a bug fix. Both are fine with me in this case. > > Thanks, > > > A cleaner solution on the long-term would be turning V9fsSynthOpenState's > > 'dent' member into a pointer and adding a new function to osdep like: > > > > struct dirent * > > qemu_dirent_new(const char* name) { > > > > ... > > > > } > > > > But I would like to postpone that qemu_dirent_new() solution, e.g. because > > I guess some people would probably not like qemu_dirent_new() to have in > > osdep, as it is probably not a general purpose function, and I am not > > keen putting qemu_dirent_new() into a different location than > > qemu_dirent_dup(), because it would raise the danger that system > > dependent code might deviate in future. > > > > Best regards, > > Christian Schoenebeck ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PULL 0/5] 9p queue 2022-02-10 2022-02-14 14:43 ` Vitaly Chikunov 2022-02-14 17:40 ` Christian Schoenebeck @ 2022-02-15 7:01 ` Greg Kurz 2022-02-16 10:30 ` Christian Schoenebeck 1 sibling, 1 reply; 20+ messages in thread From: Greg Kurz @ 2022-02-15 7:01 UTC (permalink / raw) To: Vitaly Chikunov Cc: Peter Maydell, Christian Schoenebeck, qemu-devel, Dmitry V . Levin On Mon, 14 Feb 2022 17:43:51 +0300 Vitaly Chikunov <vt@altlinux.org> wrote: > Christian, > > On Mon, Feb 14, 2022 at 12:44:48PM +0100, Christian Schoenebeck wrote: > > On Montag, 14. Februar 2022 11:36:53 CET Greg Kurz wrote: > > > The synth backend should be fixed to honor d_reclen, or > > > at least to allocate with g_new0(). > > > > Yes, I overlooked that this is not initialized with zero already. > > > > With g_new0() d_reclen would be zero and qemu_dirent_dup() would then fallback > > to the portable branch (as I assumed it already would): > > Perhaps, this additional change should be added (I only found two instances of > V9fsSynthOpenState allocation): > > diff --git a/hw/9pfs/9p-synth.c b/hw/9pfs/9p-synth.c > --- a/hw/9pfs/9p-synth.c > +++ b/hw/9pfs/9p-synth.c > @@ -182,7 +182,7 @@ static int synth_opendir(FsContext *ctx, > V9fsSynthOpenState *synth_open; > V9fsSynthNode *node = *(V9fsSynthNode **)fs_path->data; > > - synth_open = g_malloc(sizeof(*synth_open)); > + synth_open = g_malloc0(sizeof(*synth_open)); > synth_open->node = node; > node->open_count++; > fs->private = synth_open; > @@ -266,7 +266,7 @@ static int synth_open(FsContext *ctx, V9fsPath *fs_path, > V9fsSynthOpenState *synth_open; > V9fsSynthNode *node = *(V9fsSynthNode **)fs_path->data; > > - synth_open = g_malloc(sizeof(*synth_open)); > + synth_open = g_malloc0(sizeof(*synth_open)); > synth_open->node = node; > node->open_count++; > fs->private = synth_open; > > > Additionally I would add NAME_MAX to the V9fsSynthOpenState allocation size, > > because it is known that some systems define dirent as flex-array (zero d_name > > size). > > (To be precise) not just zero, but 1 byte. Also, to remind, for some > filesystems, such as CIFS, actual d_name size could be longer than NAME_MAX. > Because of that struct dirent cannot be allocated statically or with simple > sizeof. > > > > > I know Greg would not favour this solution (using g_new0), but it's the most > > minimalistic and most portable solution. So I would favour it for now. > > Why g_new0 and not just g_malloc0? This is smallest code change, which seems > appropriate for a bug fix. > I prefer g_new0() for the exact reasons that are provided in QEMU's official coding style docs/devel/style.rst: --- Prefer ``g_new(T, n)`` instead of ``g_malloc(sizeof(T) * n)`` for the following reasons: * It catches multiplication overflowing size_t; * It returns T ``*`` instead of void ``*``, letting compiler catch more type errors. Declarations like .. code-block:: c T *v = g_malloc(sizeof(*v)) are acceptable, though. --- I'm fine with the acceptable version as well. The only important thing is to fix the synth backend. Cheers, -- Greg > Thanks, > > > > > A cleaner solution on the long-term would be turning V9fsSynthOpenState's > > 'dent' member into a pointer and adding a new function to osdep like: > > > > struct dirent * > > qemu_dirent_new(const char* name) { > > ... > > } > > > > But I would like to postpone that qemu_dirent_new() solution, e.g. because I > > guess some people would probably not like qemu_dirent_new() to have in osdep, > > as it is probably not a general purpose function, and I am not keen putting > > qemu_dirent_new() into a different location than qemu_dirent_dup(), because it > > would raise the danger that system dependent code might deviate in future. > > > > Best regards, > > Christian Schoenebeck > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL 0/5] 9p queue 2022-02-10 2022-02-15 7:01 ` Greg Kurz @ 2022-02-16 10:30 ` Christian Schoenebeck 2022-02-16 14:23 ` Greg Kurz ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Christian Schoenebeck @ 2022-02-16 10:30 UTC (permalink / raw) To: qemu-devel; +Cc: Greg Kurz, Vitaly Chikunov, Peter Maydell, Dmitry V . Levin On Dienstag, 15. Februar 2022 08:01:37 CET Greg Kurz wrote: > On Mon, 14 Feb 2022 17:43:51 +0300 > > Vitaly Chikunov <vt@altlinux.org> wrote: > > Why g_new0 and not just g_malloc0? This is smallest code change, which > > seems appropriate for a bug fix. > > I prefer g_new0() for the exact reasons that are provided in QEMU's > official coding style docs/devel/style.rst: [...] > I'm fine with the acceptable version as well. The only important thing is > to fix the synth backend. > > Cheers, Hi, is anybody working on a v5 of this patch? If not I will send one this evening to bring this issue forward, because it is blocking my queue. Best regards, Christian Schoenebeck ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL 0/5] 9p queue 2022-02-10 2022-02-16 10:30 ` Christian Schoenebeck @ 2022-02-16 14:23 ` Greg Kurz 2022-02-16 15:19 ` Philippe Mathieu-Daudé via 2022-02-16 16:09 ` Vitaly Chikunov 2 siblings, 0 replies; 20+ messages in thread From: Greg Kurz @ 2022-02-16 14:23 UTC (permalink / raw) To: Christian Schoenebeck Cc: Vitaly Chikunov, Peter Maydell, qemu-devel, Dmitry V . Levin On Wed, 16 Feb 2022 11:30:12 +0100 Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > On Dienstag, 15. Februar 2022 08:01:37 CET Greg Kurz wrote: > > On Mon, 14 Feb 2022 17:43:51 +0300 > > > > Vitaly Chikunov <vt@altlinux.org> wrote: > > > Why g_new0 and not just g_malloc0? This is smallest code change, which > > > seems appropriate for a bug fix. > > > > I prefer g_new0() for the exact reasons that are provided in QEMU's > > official coding style docs/devel/style.rst: > [...] > > I'm fine with the acceptable version as well. The only important thing is > > to fix the synth backend. > > > > Cheers, > > Hi, is anybody working on a v5 of this patch? If not I will send one this > evening to bring this issue forward, because it is blocking my queue. > I'm not, please post a patch and I'll review it ASAP. Cheers, -- Greg > Best regards, > Christian Schoenebeck > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL 0/5] 9p queue 2022-02-10 2022-02-16 10:30 ` Christian Schoenebeck 2022-02-16 14:23 ` Greg Kurz @ 2022-02-16 15:19 ` Philippe Mathieu-Daudé via 2022-02-16 16:09 ` Vitaly Chikunov 2 siblings, 0 replies; 20+ messages in thread From: Philippe Mathieu-Daudé via @ 2022-02-16 15:19 UTC (permalink / raw) To: Christian Schoenebeck, qemu-devel Cc: Greg Kurz, Vitaly Chikunov, Peter Maydell, Dmitry V . Levin On 16/2/22 11:30, Christian Schoenebeck wrote: > On Dienstag, 15. Februar 2022 08:01:37 CET Greg Kurz wrote: >> On Mon, 14 Feb 2022 17:43:51 +0300 >> >> Vitaly Chikunov <vt@altlinux.org> wrote: >>> Why g_new0 and not just g_malloc0? This is smallest code change, which >>> seems appropriate for a bug fix. >> >> I prefer g_new0() for the exact reasons that are provided in QEMU's >> official coding style docs/devel/style.rst: > [...] >> I'm fine with the acceptable version as well. The only important thing is >> to fix the synth backend. >> >> Cheers, > > Hi, is anybody working on a v5 of this patch? If not I will send one this > evening to bring this issue forward, because it is blocking my queue. If a patch blocks your tree queue, you can simply drop it, ask the contributor to rework it, and keep merging your tree... ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL 0/5] 9p queue 2022-02-10 2022-02-16 10:30 ` Christian Schoenebeck 2022-02-16 14:23 ` Greg Kurz 2022-02-16 15:19 ` Philippe Mathieu-Daudé via @ 2022-02-16 16:09 ` Vitaly Chikunov 2022-02-16 16:20 ` Christian Schoenebeck 2 siblings, 1 reply; 20+ messages in thread From: Vitaly Chikunov @ 2022-02-16 16:09 UTC (permalink / raw) To: Christian Schoenebeck Cc: Peter Maydell, Dmitry V . Levin, qemu-devel, Greg Kurz Christian, On Wed, Feb 16, 2022 at 11:30:12AM +0100, Christian Schoenebeck wrote: > On Dienstag, 15. Februar 2022 08:01:37 CET Greg Kurz wrote: > > On Mon, 14 Feb 2022 17:43:51 +0300 > > > > Vitaly Chikunov <vt@altlinux.org> wrote: > > > Why g_new0 and not just g_malloc0? This is smallest code change, which > > > seems appropriate for a bug fix. > > > > I prefer g_new0() for the exact reasons that are provided in QEMU's > > official coding style docs/devel/style.rst: > [...] > > I'm fine with the acceptable version as well. The only important thing is > > to fix the synth backend. > > > > Cheers, > > Hi, is anybody working on a v5 of this patch? If not I will send one this > evening to bring this issue forward, because it is blocking my queue. I will send in a few hours if it's not too late. Thanks, > > Best regards, > Christian Schoenebeck > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PULL 0/5] 9p queue 2022-02-10 2022-02-16 16:09 ` Vitaly Chikunov @ 2022-02-16 16:20 ` Christian Schoenebeck 0 siblings, 0 replies; 20+ messages in thread From: Christian Schoenebeck @ 2022-02-16 16:20 UTC (permalink / raw) To: Vitaly Chikunov; +Cc: qemu-devel, Greg Kurz, Peter Maydell, Dmitry V . Levin On Mittwoch, 16. Februar 2022 17:09:56 CET Vitaly Chikunov wrote: > Christian, > > On Wed, Feb 16, 2022 at 11:30:12AM +0100, Christian Schoenebeck wrote: > > On Dienstag, 15. Februar 2022 08:01:37 CET Greg Kurz wrote: > > > On Mon, 14 Feb 2022 17:43:51 +0300 > > > > > > Vitaly Chikunov <vt@altlinux.org> wrote: > > > > Why g_new0 and not just g_malloc0? This is smallest code change, which > > > > seems appropriate for a bug fix. > > > > > > I prefer g_new0() for the exact reasons that are provided in QEMU's > > > > > official coding style docs/devel/style.rst: > > [...] > > > > > I'm fine with the acceptable version as well. The only important thing > > > is > > > to fix the synth backend. > > > > > > Cheers, > > > > Hi, is anybody working on a v5 of this patch? If not I will send one this > > evening to bring this issue forward, because it is blocking my queue. > > I will send in a few hours if it's not too late. Great! I would have been also just able to do that in several hours. Best regards, Christian Schoenebeck ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2022-02-16 16:21 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-02-10 11:21 [PULL 0/5] 9p queue 2022-02-10 Christian Schoenebeck 2022-02-10 11:21 ` [PULL 3/5] tests/9pfs: Fix leak of local_test_path Christian Schoenebeck 2022-02-10 11:21 ` [PULL 5/5] 9pfs: Fix segfault in do_readdir_many caused by struct dirent overread Christian Schoenebeck 2022-02-10 11:21 ` [PULL 2/5] tests/9pfs: fix mkdir() being called twice Christian Schoenebeck 2022-02-10 11:21 ` [PULL 1/5] tests/9pfs: use g_autofree where possible Christian Schoenebeck 2022-02-10 11:21 ` [PULL 4/5] tests/9pfs: Use g_autofree and g_autoptr " Christian Schoenebeck 2022-02-13 20:33 ` [PULL 0/5] 9p queue 2022-02-10 Peter Maydell 2022-02-14 9:47 ` Christian Schoenebeck 2022-02-14 9:55 ` Peter Maydell 2022-02-14 12:09 ` Christian Schoenebeck 2022-02-14 10:36 ` Greg Kurz 2022-02-14 11:44 ` Christian Schoenebeck 2022-02-14 14:43 ` Vitaly Chikunov 2022-02-14 17:40 ` Christian Schoenebeck 2022-02-15 7:01 ` Greg Kurz 2022-02-16 10:30 ` Christian Schoenebeck 2022-02-16 14:23 ` Greg Kurz 2022-02-16 15:19 ` Philippe Mathieu-Daudé via 2022-02-16 16:09 ` Vitaly Chikunov 2022-02-16 16:20 ` Christian Schoenebeck
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.