500 Internal Server Error: Cherry-picking Commit using Malformed Dictionary
Summary
500 Internal Server Error when cherry-picking a commit with a malformed dictionary.
Example
curl -v -X 'POST' -H "Content-Type: application/json" -H 'PRIVATE-TOKEN: NXuzbfpruit7PNyXTuH7' curl -v -X 'POST' -H "Content-Type: application/json" -H 'PRIVATE-TOKEN: NXuzbfpruit7PNyXTuH7' 'http://127.0.0.1/api/v4/projects' -d '{"name":"project1"}'
curl -v -X 'POST' -H "Content-Type: application/json" -H 'PRIVATE-TOKEN: NXuzbfpruit7PNyXTuH7' 'http://127.0.0.1/api/v4/projects/7/repository/commits' -d '{"branch":"master", "commit_message": "some commit message", "actions": [{"action": "create","file_path":"foo/bar","content":"some content"}]}'
echo -e '{"cont\xd0ent": "string"}' | curl -v -X 'POST' -H "Content-Type: application/json" -H 'PRIVATE-TOKEN: NXuzbfpruit7PNyXTuH7' 'http://127.0.0.1/api/v4/projects/7/repository/commits/7b66775d7703dd0b0aa97e29c18f733d9e80581d/cherry-pick' -d @-Example Project
The bug is reproducible on "gitlab.com" and on our local deployment with source code installation of enterprise edition (13-0-stable branch).
What is the current bug behavior?
HTTP Response: "500 Internal Server Error."
What is the expected correct behavior?
HTTP Response: "400 Bad Request: {"error":"dictionary is invalid"}"
Relevant logs and/or screenshots
==> /home/git/gitlab/log/production.log <==
Started POST "/api/v4/projects/7/repository/commits/7b66775d7703dd0b0aa97e29c18f733d9e80581d/cherry-pick" for 127.0.0.1 at 2020-06-24 17:20:59 +0000
ArgumentError (invalid byte sequence in UTF-8):
lib/gitlab/request_profiler/middleware.rb:17:in `call'
lib/gitlab/middleware/go.rb:20:in `call'
lib/gitlab/etag_caching/middleware.rb:13:in `call'
lib/gitlab/middleware/multipart.rb:125:in `call'
lib/gitlab/middleware/read_only/controller.rb:51:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/same_site_cookies.rb:27:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/middleware/request_context.rb:23:in `call'
config/initializers/fix_local_cache_middleware.rb:9:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:60:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call'
==> /home/git/gitlab/log/gitlab-workhorse.log <==
127.0.0.1 127.0.0.1 - - [2020/06/24:17:20:59 +0000] "POST /api/v4/projects/7/repository/commits/7b66775d7703dd0b0aa97e29c18f733d9e80581d/cherry-pick HTTP/1.1" 500 2926 "" "curl/7.58.0" 10
==> /home/git/gitlab/log/puma.stdout.log <==
{"timestamp":"2020-06-24T17:21:02.999Z","pid":4971,"message":"PumaWorkerKiller: Consuming 2189.40625 mb with master and 3 workers."}
Results of GitLab application Check
Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 13.2.0 ? ... OK (13.2.0)
Running /home/git/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab App ...
Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Init script exists? ... yes
Init script up-to-date? ... yes
Projects have namespace: ... can't check, you have no projects
Redis version >= 4.0.0? ... yes
Ruby version >= 2.5.3 ? ... yes (2.6.6)
Git version >= 2.22.0 ? ... yes (2.27.0)
Git user has default SSH configuration? ... yes
Active users: ... 1
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Checking GitLab App ... Finished
Checking GitLab subtasks ... FinishedComments
This bug was found using REST API fuzzing.