| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20240926120753.3639404-1-zhaomzhao@126.com> Date: Thu, 26 Sep 2024 20:07:50 +0800 From: Zhao Mengmeng <zhaomzhao@....com> To: jack@...e.com, zhaomengmeng@...inos.cn Cc: linux-kernel@...r.kernel.org Subject: [PATCH v2 0/3] udf: refactor udf_current_aext()/udf_next_aext()/inode_bmap() to handle error From: Zhao Mengmeng <zhaomengmeng@...inos.cn> syzbot reports a udf slab-out-of-bounds at [1] and I proposed a fix patch, after talking with Jan, a better way to fix this is to refactor udf_current_aext() and udf_next_aext() to differentiate between error and "hit EOF". This series refactor udf_current_aext(), udf_next_aext() and inode_bmap(), they take pointer to etype to store the extent type and just return 0 on success, <0 on error. It has passed the syz repro test. [1]. https://lore.kernel.org/all/0000000000005093590621340ecf@google.com/ changelog: v2: ---- - Take advices of Jan to fix the error handling code - Check all other places that may involves EOF and error checking - Add two macros the simply the error checking of extent v1: ---- - https://lore.kernel.org/all/20240918093634.12906-1-zhaomzhao@126.com/ Zhao Mengmeng (3): udf: refactor udf_current_aext() to handle error udf: refactor udf_next_aext() to handle error udf: refactor inode_bmap() to handle error fs/udf/balloc.c | 22 +++++-- fs/udf/directory.c | 23 +++++-- fs/udf/inode.c | 155 +++++++++++++++++++++++++++++---------------- fs/udf/partition.c | 6 +- fs/udf/super.c | 3 +- fs/udf/truncate.c | 41 ++++++++---- fs/udf/udfdecl.h | 18 ++++-- 7 files changed, 180 insertions(+), 88 deletions(-) -- 2.43.0
Powered by blists - more mailing lists