[PATCH] Fix segmentation fault when using xfs_quota state command.

[PATCH] Fix segmentation fault when using xfs_quota state command.

[Utako Kusaka]

Hi,

state command in xfs_quota causes segmentation fault when the path list is empty.
This patch fixes it.

Example:
# ./xfs_quota -x
xfs_quota_orig> path
xfs_quota_orig> state
Segmentation fault

Signed-off-by: Utako Kusaka <utako@tnes.nec.co.jp>
---

--- xfsprogs-2.8.20/quota/state.orig	2007-04-19 13:07:38.000000000 +0900
+++ xfsprogs-2.8.20/quota/state.c	2007-04-27 11:23:30.000000000 +0900
@@ -226,6 +226,9 @@ state_f(
 	if (argc != optind)
 		return command_usage(&state_cmd);
 
+	if (!fs_count)
+		return 0;
+
 	if ((fp = fopen_write_secure(fname)) == NULL)
 		return 0;

 
 

Re: [PATCH] Fix segmentation fault when using xfs_quota state command.

[Nathan Scott]

On Fri, 2007-04-27 at 11:40 +0900, Utako Kusaka wrote:
> +	if (!fs_count)
> +		return 0;
> +

Is the segfault due to this line in state.c?
237             else if (fs_path->fs_flags & FS_MOUNT_POINT)

If so, a fix that is more clear to the reader might be:

- else if (fs_path->fs_flags & FS_MOUNT_POINT)
+ else if (fs_path && fs_path->fs_flags & FS_MOUNT_POINT)

This keeps the fix alongside the problematic access to fs_path.

cheers.

-- 
Nathan

Re: [PATCH] Fix segmentation fault when using xfs_quota state command.

[Utako Kusaka]

Thanks for your comment.
I thought processes after fopen_write_secure() is not necessary
when the path list is empty.
But is creating an empty file necessary when specifying -f option?
This option isn't written in man page:)

--
Utako

Fri, 27 Apr 2007 13:58:22 +1000 Nathan Scott wrote：
>On Fri, 2007-04-27 at 11:40 +0900, Utako Kusaka wrote:
>> +	if (!fs_count)
>> +		return 0;
>> +
>
>Is the segfault due to this line in state.c?
>237             else if (fs_path->fs_flags & FS_MOUNT_POINT)
>
>If so, a fix that is more clear to the reader might be:
>
>- else if (fs_path->fs_flags & FS_MOUNT_POINT)
>+ else if (fs_path && fs_path->fs_flags & FS_MOUNT_POINT)
>
>This keeps the fix alongside the problematic access to fs_path.
>
>cheers.
>
>-- 
>Nathan