New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dsi_stream_read: len:0, unexpected EOF #82

Closed
slowfranklin opened this Issue Feb 2, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@slowfranklin
Member

slowfranklin commented Feb 2, 2017

Due to a bug in the handling of extended attributes, certain xattr related operations could result in a broken connection. An application that seems to trigger is reliably is Photos.app.

Patch to follow...

slowfranklin added a commit that referenced this issue Feb 2, 2017

libatalk: fix sys_fgetxattr on BSD
The BSD implementation of the sys_fgetxattr() function was lacking a
check already present in sys_getxattr(): if the input parameter is 0
we're supposed to return the xattr size and not return ERANGE.

Bug: #82

Signed-off-by: Ralph Boehme <slow@samba.org>

slowfranklin added a commit that referenced this issue Feb 2, 2017

libatalk/vfs: use helper variable
Instead of changing maxreply use a helper variable, no change in
behaviour.

Bug: #82

Signed-off-by: Ralph Boehme <slow@samba.org>

slowfranklin added a commit that referenced this issue Feb 2, 2017

libatalk/vfs: fix handling of short req_count when fetching xattr
This fixes several issue:

1. MAX_REPLY_EXTRA_BYTES was wrong, it is 6, not 8. 6 bytes for the AFP
response bitmap (2) and length (4)

2. We must protect us against bogus MAX_REPLY_EXTRA_BYTES, otherwise
maxreply can underflow or become zero. The latter would be interpreted
as a request to get the xattr size, not the content.

3. If the underylying xattr API reports ERANGE then the xattr is larger
then the requested size, we must return this as AFPERR_PARAM to the
client.

See also commit 66b5b77991679fa8b0b910d159f8592c5414b2b6 and the new
test 432 in our test-suite.

Bug: #82

Signed-off-by: Ralph Boehme <slow@samba.org>

hat001 added a commit that referenced this issue Feb 10, 2017

libatalk: fix sys_fgetxattr on BSD
The BSD implementation of the sys_fgetxattr() function was lacking a
check already present in sys_getxattr(): if the input parameter is 0
we're supposed to return the xattr size and not return ERANGE.

Bug: #82

Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: HAT <hat@fa2.so-net.ne.jp>

hat001 added a commit that referenced this issue Feb 10, 2017

libatalk/vfs: use helper variable
Instead of changing maxreply use a helper variable, no change in
behaviour.

Bug: #82

Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: HAT <hat@fa2.so-net.ne.jp>

hat001 added a commit that referenced this issue Feb 10, 2017

libatalk/vfs: fix handling of short req_count when fetching xattr
This fixes several issue:

1. MAX_REPLY_EXTRA_BYTES was wrong, it is 6, not 8. 6 bytes for the AFP
response bitmap (2) and length (4)

2. We must protect us against bogus MAX_REPLY_EXTRA_BYTES, otherwise
maxreply can underflow or become zero. The latter would be interpreted
as a request to get the xattr size, not the content.

3. If the underylying xattr API reports ERANGE then the xattr is larger
then the requested size, we must return this as AFPERR_PARAM to the
client.

See also commit 66b5b77991679fa8b0b910d159f8592c5414b2b6 and the new
test 432 in our test-suite.

Bug: #82

Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: HAT <hat@fa2.so-net.ne.jp>

hat001 added a commit that referenced this issue Feb 11, 2017

libatalk: fix sys_fgetxattr on BSD
The BSD implementation of the sys_fgetxattr() function was lacking a
check already present in sys_getxattr(): if the input parameter is 0
we're supposed to return the xattr size and not return ERANGE.

Bug: #82

Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: HAT <hat@fa2.so-net.ne.jp>
(cherry picked from commit f246d62)

hat001 added a commit that referenced this issue Feb 11, 2017

libatalk/vfs: use helper variable
Instead of changing maxreply use a helper variable, no change in
behaviour.

Bug: #82

Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: HAT <hat@fa2.so-net.ne.jp>
(cherry picked from commit cdfccb6)

hat001 added a commit that referenced this issue Feb 11, 2017

libatalk/vfs: fix handling of short req_count when fetching xattr
This fixes several issue:

1. MAX_REPLY_EXTRA_BYTES was wrong, it is 6, not 8. 6 bytes for the AFP
response bitmap (2) and length (4)

2. We must protect us against bogus MAX_REPLY_EXTRA_BYTES, otherwise
maxreply can underflow or become zero. The latter would be interpreted
as a request to get the xattr size, not the content.

3. If the underylying xattr API reports ERANGE then the xattr is larger
then the requested size, we must return this as AFPERR_PARAM to the
client.

See also commit 66b5b77991679fa8b0b910d159f8592c5414b2b6 and the new
test 432 in our test-suite.

Bug: #82

Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: HAT <hat@fa2.so-net.ne.jp>
(cherry picked from commit 40532b4)
@hat001

This comment has been minimized.

Show comment
Hide comment
@hat001

hat001 Feb 11, 2017

Member

commited.

Member

hat001 commented Feb 11, 2017

commited.

@hat001 hat001 closed this Feb 11, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment