{"thread":{"id":"38892","subject":"[BUG] [PATCH] infinite loop due to broken symlink","startedAt":"2015-03-23T16:04:45Z","lastAt":"2015-03-26T09:32:05Z","messageCount":4,"participants":["Petr Stodulka","Michael Haggerty","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"258367","messageId":"5510399D.4020007@redhat.com","threadId":"38892","inReplyTo":null,"subject":"[BUG] [PATCH] infinite loop due to broken symlink","fromName":"Petr Stodulka","fromEmail":"pstodulk@redhat.com","sentAt":"2015-03-23T16:04:45Z","receivedAt":"2015-03-23T16:04:45Z","isPatch":true,"sender":{"key":"pstodulk@redhat.com","avatar":"https://avatars.githubusercontent.com/u/1656374?v=4"},"body":"Hi guys,\ngit goes into an infinite loop due to broken symlink (minimal reproducer \n[0]). Affected code is in function\n\"resolve_ref_unsafe\" in file refs.c - notice 'stat_ref'. There is comment\nabout problem with race condition, hovewer in that case it's regular broken\nsymlink which cause infinite loop. Possible patch could be something \nlike this:\n\n-------------------------------------------------------\ndiff --git a/refs.c b/refs.c\nindex e23542b..9efe8d2 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -1356,6 +1356,7 @@ static struct ref_dir *get_loose_refs(struct \nref_cache *refs)\n /* We allow \"recursive\" symbolic refs. Only within reason, though */\n #define MAXDEPTH 5\n #define MAXREFLEN (1024)\n+#define MAXLOOP 1024\n\n /*\n * Called by resolve_gitlink_ref_recursive() after it failed to read\n@@ -1482,6 +1483,7 @@ const char *resolve_ref_unsafe(const char \n*refname, int resolve_flags, unsigned\n char buffer[256];\n static char refname_buffer[256];\n int bad_name = 0;\n+ int loop_counter = 0;\n\n if (flags)\n *flags = 0;\n@@ -1546,7 +1548,8 @@ const char *resolve_ref_unsafe(const char \n*refname, int resolve_flags, unsigned\n if (S_ISLNK(st.st_mode)) {\n len = readlink(path, buffer, sizeof(buffer)-1);\n if (len < 0) {\n- if (errno == ENOENT || errno == EINVAL)\n+ if (loop_counter++ < MAXLOOP &&\n+ (errno == ENOENT || errno == EINVAL))\n /* inconsistent with lstat; \nretry */\n goto stat_ref;\n else\n@@ -1579,7 +1582,7 @@ const char *resolve_ref_unsafe(const char \n*refname, int resolve_flags, unsigned\n */\n fd = open(path, O_RDONLY);\n if (fd < 0) {\n- if (errno == ENOENT)\n+ if (loop_counter++ < MAXLOOP && errno == ENOENT)\n /* inconsistent with lstat; retry */\n goto stat_ref;\n else\n-------------------------------------------------------\n\nIf I understand well that simple check of broken symlink is not possible\ndue to race conditions.\n\nRegards,\nPetr\n\n[0] https://bugzilla.redhat.com/show_bug.cgi?id=1204193\n"},{"id":"258529","messageId":"55133C63.2010805@alum.mit.edu","threadId":"38892","inReplyTo":"5510399D.4020007@redhat.com","subject":"Re: [BUG] [PATCH] infinite loop due to broken symlink","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2015-03-25T22:53:23Z","receivedAt":"2015-03-25T22:53:23Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/23/2015 05:04 PM, Petr Stodulka wrote:\n> git goes into an infinite loop due to broken symlink (minimal reproducer\n> [0]). Affected code is in function\n> \"resolve_ref_unsafe\" in file refs.c - notice 'stat_ref'. There is comment\n> about problem with race condition, hovewer in that case it's regular broken\n> symlink which cause infinite loop.\n\nThanks for the bug report. I can confirm the problem. In fact, I noticed\nthe same problem when I was working on a refactoring in the area, but I\nstill haven't submitted those patches. Luckily, modern Git doesn't use\nsymlinks in the loose reference hierarchy, so most users will never\nencounter this problem.\n\nIn fact I think it is only the open() call that can lead to the infinite\nloop. Meanwhile, there is another problem caused by falling through the\nsymlink-handling code, namely that st reflects the lstat() of the\nsymlink rather than the stat() of the file that it points to.\n\nMy approach was to run stat() on the path if the symlink-handling code\nfalls through. You can see my work in progress in my GitHub repo [1].\n\n> Possible patch could be something\n> like this:\n> \n> -------------------------------------------------------\n> diff --git a/refs.c b/refs.c\n> index e23542b..9efe8d2 100644\n> --- a/refs.c\n> +++ b/refs.c\n> @@ -1356,6 +1356,7 @@ static struct ref_dir *get_loose_refs(struct\n> ref_cache *refs)\n> /* We allow \"recursive\" symbolic refs. Only within reason, though */\n> #define MAXDEPTH 5\n> #define MAXREFLEN (1024)\n> +#define MAXLOOP 1024\n> \n> /*\n> * Called by resolve_gitlink_ref_recursive() after it failed to read\n> @@ -1482,6 +1483,7 @@ const char *resolve_ref_unsafe(const char\n> *refname, int resolve_flags, unsigned\n> char buffer[256];\n> static char refname_buffer[256];\n> int bad_name = 0;\n> + int loop_counter = 0;\n> \n> if (flags)\n> *flags = 0;\n> @@ -1546,7 +1548,8 @@ const char *resolve_ref_unsafe(const char\n> *refname, int resolve_flags, unsigned\n> if (S_ISLNK(st.st_mode)) {\n> len = readlink(path, buffer, sizeof(buffer)-1);\n> if (len < 0) {\n> - if (errno == ENOENT || errno == EINVAL)\n> + if (loop_counter++ < MAXLOOP &&\n> + (errno == ENOENT || errno == EINVAL))\n> /* inconsistent with lstat;\n> retry */\n> goto stat_ref;\n> else\n> @@ -1579,7 +1582,7 @@ const char *resolve_ref_unsafe(const char\n> *refname, int resolve_flags, unsigned\n> */\n> fd = open(path, O_RDONLY);\n> if (fd < 0) {\n> - if (errno == ENOENT)\n> + if (loop_counter++ < MAXLOOP && errno == ENOENT)\n> /* inconsistent with lstat; retry */\n> goto stat_ref;\n> else\n> -------------------------------------------------------\n> \n> If I understand well that simple check of broken symlink is not possible\n> due to race conditions.\n\nThis change also prevents the infinite loop, in fact in a more failproof\nway that doesn't depend on errno values being interpreted correctly. I\nwould suggest a few stylistic changes, like for example here [2]. On the\nother hand, this change doesn't solve the lstat()/stat() problem.\n\nNevertheless, I wouldn't object to a fix like this being accepted in\naddition to the stat() fix when it's ready. It doesn't hurt to wear both\na belt *and* suspenders.\n\nMichael\n\n[1] https://github.com/mhagger/git, branch \"wip/refactor-resolve-ref\".\n See especially commit d2425d8ac8cf73494b318078b92f5b1c510a68fb.\n[2] https://github.com/mhagger/git, branch \"ref-broken-symlinks\"\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\n"},{"id":"258530","messageId":"xmqq1tkc1x49.fsf@gitster.dls.corp.google.com","threadId":"38892","inReplyTo":"55133C63.2010805@alum.mit.edu","subject":"Re: [BUG] [PATCH] infinite loop due to broken symlink","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-25T23:21:58Z","receivedAt":"2015-03-25T23:21:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> Thanks for the bug report. I can confirm the problem. In fact, I noticed\n> the same problem when I was working on a refactoring in the area, but I\n> still haven't submitted those patches.\n\nThanks. It is nice to know that the refs.c API refactoring is still\nbeing worked on.\n"},{"id":"258540","messageId":"5513D215.4070806@redhat.com","threadId":"38892","inReplyTo":"55133C63.2010805@alum.mit.edu","subject":"Re: [BUG] [PATCH] infinite loop due to broken symlink","fromName":"Petr Stodulka","fromEmail":"pstodulk@redhat.com","sentAt":"2015-03-26T09:32:05Z","receivedAt":"2015-03-26T09:32:05Z","isPatch":true,"sender":{"key":"pstodulk@redhat.com","avatar":"https://avatars.githubusercontent.com/u/1656374?v=4"},"body":"\nOn 25.3.2015 23:53 Michael Haggerty wrote:\n> On 03/23/2015 05:04 PM, Petr Stodulka wrote:\n>> git goes into an infinite loop due to broken symlink (minimal reproducer\n>> [0]). Affected code is in function\n>> \"resolve_ref_unsafe\" in file refs.c - notice 'stat_ref'. There is comment\n>> about problem with race condition, hovewer in that case it's regular broken\n>> symlink which cause infinite loop.\n> Thanks for the bug report. I can confirm the problem. In fact, I noticed\n> the same problem when I was working on a refactoring in the area, but I\n> still haven't submitted those patches. Luckily, modern Git doesn't use\n> symlinks in the loose reference hierarchy, so most users will never\n> encounter this problem.\n>\n> In fact I think it is only the open() call that can lead to the infinite\n> loop. Meanwhile, there is another problem caused by falling through the\n> symlink-handling code, namely that st reflects the lstat() of the\n> symlink rather than the stat() of the file that it points to.\n>\n> My approach was to run stat() on the path if the symlink-handling code\n> falls through. You can see my work in progress in my GitHub repo [1].\n>\nYes, I thought up about similar solution, but I wasn't sure about this way\nbecause of race condition (I don't know well code of git yet). In the case\nof approved lstat/stat patch, I am more familiar with this solution.\n>> Possible patch could be something\n>> like this:\n>>\n>> -------------------------------------------------------\n>> diff --git a/refs.c b/refs.c\n>> index e23542b..9efe8d2 100644\n>> --- a/refs.c\n>> +++ b/refs.c\n>> @@ -1356,6 +1356,7 @@ static struct ref_dir *get_loose_refs(struct\n>> ref_cache *refs)\n>> /* We allow \"recursive\" symbolic refs. Only within reason, though */\n>> #define MAXDEPTH 5\n>> #define MAXREFLEN (1024)\n>> +#define MAXLOOP 1024\n>>\n>> /*\n>> * Called by resolve_gitlink_ref_recursive() after it failed to read\n>> @@ -1482,6 +1483,7 @@ const char *resolve_ref_unsafe(const char\n>> *refname, int resolve_flags, unsigned\n>> char buffer[256];\n>> static char refname_buffer[256];\n>> int bad_name = 0;\n>> + int loop_counter = 0;\n>>\n>> if (flags)\n>> *flags = 0;\n>> @@ -1546,7 +1548,8 @@ const char *resolve_ref_unsafe(const char\n>> *refname, int resolve_flags, unsigned\n>> if (S_ISLNK(st.st_mode)) {\n>> len = readlink(path, buffer, sizeof(buffer)-1);\n>> if (len < 0) {\n>> - if (errno == ENOENT || errno == EINVAL)\n>> + if (loop_counter++ < MAXLOOP &&\n>> + (errno == ENOENT || errno == EINVAL))\n>> /* inconsistent with lstat;\n>> retry */\n>> goto stat_ref;\n>> else\n>> @@ -1579,7 +1582,7 @@ const char *resolve_ref_unsafe(const char\n>> *refname, int resolve_flags, unsigned\n>> */\n>> fd = open(path, O_RDONLY);\n>> if (fd < 0) {\n>> - if (errno == ENOENT)\n>> + if (loop_counter++ < MAXLOOP && errno == ENOENT)\n>> /* inconsistent with lstat; retry */\n>> goto stat_ref;\n>> else\n>> -------------------------------------------------------\n>>\n>> If I understand well that simple check of broken symlink is not possible\n>> due to race conditions.\n> This change also prevents the infinite loop, in fact in a more failproof\n> way that doesn't depend on errno values being interpreted correctly. I\n> would suggest a few stylistic changes, like for example here [2]. On the\n> other hand, this change doesn't solve the lstat()/stat() problem.\n>\n> Nevertheless, I wouldn't object to a fix like this being accepted in\n> addition to the stat() fix when it's ready. It doesn't hurt to wear both\n> a belt *and* suspenders.\n>\n> Michael\n>\n> [1] https://github.com/mhagger/git, branch \"wip/refactor-resolve-ref\".\n> See especially commit d2425d8ac8cf73494b318078b92f5b1c510a68fb.\n> [2] https://github.com/mhagger/git, branch \"ref-broken-symlinks\"\n>\nWhen stat/lstat is ready, probably this will not be valuable anymore, \nbut it\ncould be reliable 'stop' for some unexpected/unknown possibly ways in \nfuture.\n\nPetr.\n"}]}