Bug 14722 - parent_smb_fname() talloc()s atname->base_name off the wrong context.
Summary: parent_smb_fname() talloc()s atname->base_name off the wrong context.
Status: ASSIGNED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.14.5
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-01 20:18 UTC by Jeremy Allison
Modified: 2021-06-14 15:58 UTC (History)
2 users (show)

See Also:


Attachments
git-am fix for 4.14.next, 4.13.next. (965 bytes, patch)
2021-06-02 16:57 UTC, Jeremy Allison
jra: review? (slow)
npower: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Allison 2021-06-01 20:18:58 UTC
Have fix, need bugnumber.

When we're returning the struct smb_filename **atname,
we allocate the atname->base_name off the wrong talloc
context. All smb_filename->base_names should be allocated
off the parent smb_filename, but parent_smb_fname()
doesn't do this.

In the normal use-cases we pass in talloc_tos() for
the mem_ctx parameter for parent_smb_fname(), and so
mostly we don't notice the problem.

When I started using shadow_copy2 games however,
this caused *horrible* valgrind errors that took
me a couple of days to track down :-(.

Note I will fix this differently in master using the new SMB_VFS_PARENT_PATHNAME) patchset so the patches I have are for 4.14.next, 4.13.next only.
Comment 1 Jeremy Allison 2021-06-01 20:27:32 UTC
Ah, never mind. I'll fix in master first the usual way, and rebase my SMB_VFS_PARENT_PATHNAME() to cope with deleting the newly correct code, rather than the buggy code. That way I can feed through ci as normal..
Comment 2 Samba QA Contact 2021-06-02 06:31:05 UTC
This bug was referenced in samba master:

c500d99e2f5aaec102bf952b7941a2596b3e35a1
Comment 3 Jeremy Allison 2021-06-02 16:57:20 UTC
Created attachment 16640 [details]
git-am fix for 4.14.next, 4.13.next.
Comment 4 Jeremy Allison 2021-06-02 16:57:36 UTC
Comment on attachment 16640 [details]
git-am fix for 4.14.next, 4.13.next.

Cherry-picked from master.
Comment 5 Jeremy Allison 2021-06-11 16:59:06 UTC
Comment on attachment 16640 [details]
git-am fix for 4.14.next, 4.13.next.

We rather need this to prevent valgrind errors..
Comment 6 Ralph Böhme 2021-06-14 15:58:30 UTC
Reassigning to Karolin for inclusion in 4.13 and 4.14.