Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • rygel rygel
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 134
    • Issues 134
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOMEGNOME
  • rygelrygel
  • Issues
  • #137
Closed (moved) (moved)
Open
Issue created Aug 22, 2019 by Sébastien Bacher@seb128

unreachable code issues

That's part of the Ubuntu security team review done on https://bugs.launchpad.net/ubuntu/+source/rygel/+bug/1786489 , the version reviewed was 0.36.2

- Coverity shows up quite a few unreachable code issues, like this one in rygel_base_configuration_real_get_interface:
...
    g_propagate_error (error, _inner_error0_);
    return NULL;
    return result;
}

And also rygel_basic_management_test_real_run_co:
...
    }
    g_object_unref (_data_->_async_result);
    return FALSE;
    g_task_return_pointer (_data_->_async_result, _data_, NULL);
    if (_data_->_state_ != 0) {
        while (!_data_->_task_complete_) {
...

These look like vala bugs.

- There's a fd leak in rygel_energy_management_get_mac_and_network_type if fd == 0. I'm not sure if this is a real issue - it's only possible to hit this condition if stdin is closed.
- Coverity catches what looks like an obvious null deref here in rygel_ruih_service_manager_real_constructed in the second call to block1_data_unref:
...
        if (G_UNLIKELY (_inner_error0_ != NULL)) {
            _g_object_unref0 (config_dir_file);
            block1_data_unref (_data1_);
            _data1_ = NULL;
            if (_inner_error0_->domain == RYGEL_RUIH_SERVICE_ERROR) {
                goto __catch2_rygel_ruih_service_error;
            }
            if (_inner_error0_->domain == G_IO_ERROR) {
                goto __catch2_g_io_error;
            }
            _g_object_unref0 (config_dir_file);
            block1_data_unref (_data1_);
            _data1_ = NULL;
            _g_free0 (ui_listing_directory);
            g_critical ("file %s: line %d: unexpected error: %s (%s, %d)", __FILE__, __LINE__, _inner_error0_->message, g_quark_to_string (_inner_error0_->domain), _inner_error0_->code);
            g_clear_error (&_inner_error0_);
            return;
        }
...

I'm not sure if this is actually a vala bug though.
Assignee
Assign to
Time tracking