ntfs orphan? (was Re: [PATCH] ntfs: do not dereference a null ctx on error)

ntfs orphan? (was Re: [PATCH] ntfs: do not dereference a null ctx on error)

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

On Fri, Apr 07, 2023 at 07:44:33PM +0000, Danila Chernetsov wrote:
> In ntfs_mft_data_extend_allocation_nolock(), if an error condition occurs
> prior to 'ctx' being set to a non-NULL value, avoid dereferencing the NULL
> 'ctx' pointer in error handling.
> 
> Found by Linux Verification Center (linuxtesting.org) with SVACE.

Duplicate of 10-years-old outstanding patch at [1].

I'm not speaking of the patch itself but rather on unfortunate state
of ntfs subsystem. It seems like the maintainer is MIA (has not
responding to patch submissions for a long time). Some trivial
patches, however, are merged through mm tree.

Konstantin (from newer ntfs3 subsystem), Andrew, would you like to take a
look on this orphaned subsystem (and help reviewing)? I'd like to send
MAINTAINERS update if it turns out to be the case.

Thanks.

[1]: https://lore.kernel.org/all/1358389709-20561-1-git-send-email-nickolai@csail.mit.edu/

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: ntfs orphan? (was Re: [PATCH] ntfs: do not dereference a null ctx on error)

[Andrew Morton]

On Wed, 3 May 2023 11:16:02 +0700 Bagas Sanjaya <bagasdotme@gmail.com> wrote:

> On Fri, Apr 07, 2023 at 07:44:33PM +0000, Danila Chernetsov wrote:
> > In ntfs_mft_data_extend_allocation_nolock(), if an error condition occurs
> > prior to 'ctx' being set to a non-NULL value, avoid dereferencing the NULL
> > 'ctx' pointer in error handling.
> > 
> > Found by Linux Verification Center (linuxtesting.org) with SVACE.
> 
> Duplicate of 10-years-old outstanding patch at [1].

Well, the patches are actually quite different.  Is Danila's longer one
better?

> I'm not speaking of the patch itself but rather on unfortunate state
> of ntfs subsystem. It seems like the maintainer is MIA (has not
> responding to patch submissions for a long time). Some trivial
> patches, however, are merged through mm tree.
> 
> Konstantin (from newer ntfs3 subsystem), Andrew, would you like to take a
> look on this orphaned subsystem (and help reviewing)? I'd like to send
> MAINTAINERS update if it turns out to be the case.
> 

Sure, I can join linux-ntfs-dev@lists.sourceforge.net and hendle things
which come along.

Or Christian may want to do that?

> 
> [1]: https://lore.kernel.org/all/1358389709-20561-1-git-send-email-nickolai@csail.mit.edu/

Re: ntfs orphan? (was Re: [PATCH] ntfs: do not dereference a null ctx on error)

[Anton Altaparmakov]

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

Hi,

On 3 May 2023, at 22:06, Andrew Morton <akpm@linux-foundation.org> wrote:
On Wed, 3 May 2023 11:16:02 +0700 Bagas Sanjaya <bagasdotme@gmail.com> wrote:
On Fri, Apr 07, 2023 at 07:44:33PM +0000, Danila Chernetsov wrote:
In ntfs_mft_data_extend_allocation_nolock(), if an error condition occurs
prior to 'ctx' being set to a non-NULL value, avoid dereferencing the NULL
'ctx' pointer in error handling.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Duplicate of 10-years-old outstanding patch at [1].

Well, the patches are actually quite different.  Is Danila's longer one
better?

Yes, I think the new, longer one is much nicer.  Please take that one.  Oh just noticed the next email in my inbox - you already have, thank you.

I'm not speaking of the patch itself but rather on unfortunate state
of ntfs subsystem. It seems like the maintainer is MIA (has not
responding to patch submissions for a long time). Some trivial
patches, however, are merged through mm tree.

Konstantin (from newer ntfs3 subsystem), Andrew, would you like to take a
look on this orphaned subsystem (and help reviewing)? I'd like to send
MAINTAINERS update if it turns out to be the case.


Sure, I can join linux-ntfs-dev@lists.sourceforge.net and hendle things
which come along.

Or Christian may want to do that?

Sorry, I am not totally MIA - I do handle the odd patch but I do miss many.  Sorry to say I have been so busy it is very easy for things to slip through my attention or to be read and then forgotten and my inbox is currently at 79213 messages so the old patch is probably somewhere in there just chances of me ever getting to the bottom of my inbox and dealing with all those old messages is close to zero given I am losing ground constantly rather than winning it.  I am trying just not succeeding very well...

Best regards,

Anton



[1]: https://lore.kernel.org/all/1358389709-20561-1-git-send-email-nickolai@csail.mit.edu/



--
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer


[-- Attachment #2: Type: text/html, Size: 3182 bytes --]

Re: ntfs orphan? (was Re: [PATCH] ntfs: do not dereference a null ctx on error)

[Christian Brauner]

On Wed, May 03, 2023 at 02:06:09PM -0700, Andrew Morton wrote:
> On Wed, 3 May 2023 11:16:02 +0700 Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> 
> > On Fri, Apr 07, 2023 at 07:44:33PM +0000, Danila Chernetsov wrote:
> > > In ntfs_mft_data_extend_allocation_nolock(), if an error condition occurs
> > > prior to 'ctx' being set to a non-NULL value, avoid dereferencing the NULL
> > > 'ctx' pointer in error handling.
> > > 
> > > Found by Linux Verification Center (linuxtesting.org) with SVACE.
> > 
> > Duplicate of 10-years-old outstanding patch at [1].
> 
> Well, the patches are actually quite different.  Is Danila's longer one
> better?
> 
> > I'm not speaking of the patch itself but rather on unfortunate state
> > of ntfs subsystem. It seems like the maintainer is MIA (has not
> > responding to patch submissions for a long time). Some trivial
> > patches, however, are merged through mm tree.
> > 
> > Konstantin (from newer ntfs3 subsystem), Andrew, would you like to take a
> > look on this orphaned subsystem (and help reviewing)? I'd like to send
> > MAINTAINERS update if it turns out to be the case.
> > 
> 
> Sure, I can join linux-ntfs-dev@lists.sourceforge.net and hendle things
> which come along.
> 
> Or Christian may want to do that?

Thanks for asking. I would be able to pick up those patches into
fs.misc. I got an off-list ping about someone also wanting to help
with review apparently.

Re: ntfs orphan? (was Re: [PATCH] ntfs: do not dereference a null ctx on error)

[Namjae Jeon]

2023-05-04 6:06 GMT+09:00, Andrew Morton <akpm@linux-foundation.org>:
> On Wed, 3 May 2023 11:16:02 +0700 Bagas Sanjaya <bagasdotme@gmail.com>
> wrote:
>
>> On Fri, Apr 07, 2023 at 07:44:33PM +0000, Danila Chernetsov wrote:
>> > In ntfs_mft_data_extend_allocation_nolock(), if an error condition
>> > occurs
>> > prior to 'ctx' being set to a non-NULL value, avoid dereferencing the
>> > NULL
>> > 'ctx' pointer in error handling.
>> >
>> > Found by Linux Verification Center (linuxtesting.org) with SVACE.
>>
>> Duplicate of 10-years-old outstanding patch at [1].
>
> Well, the patches are actually quite different.  Is Danila's longer one
> better?
Danila's patch is better than old one. old patch doesn't free
allocated cluster in error handling. And Christian will apply this to
his queue if you drop this patch.
>
>> I'm not speaking of the patch itself but rather on unfortunate state
>> of ntfs subsystem. It seems like the maintainer is MIA (has not
>> responding to patch submissions for a long time). Some trivial
>> patches, however, are merged through mm tree.
>>
>> Konstantin (from newer ntfs3 subsystem), Andrew, would you like to take a
>> look on this orphaned subsystem (and help reviewing)? I'd like to send
>> MAINTAINERS update if it turns out to be the case.
>>
>
> Sure, I can join linux-ntfs-dev@lists.sourceforge.net and hendle things
> which come along.
>
> Or Christian may want to do that?
>
>>
>> [1]:
>> https://lore.kernel.org/all/1358389709-20561-1-git-send-email-nickolai@csail.mit.edu/
>
>
>