• Charles Keepax's avatar
    regmap: debugfs: Fix handling of name string for debugfs init delays · 94cc89eb
    Charles Keepax authored
    In regmap_debugfs_init the initialisation of the debugfs is delayed
    if the root node isn't ready yet. Most callers of regmap_debugfs_init
    pass the name from the regmap_config, which is considered temporary
    ie. may be unallocated after the regmap_init call returns. This leads
    to a potential use after free, where config->name has been freed by
    the time it is used in regmap_debugfs_initcall.
    
    This situation can be seen on Zynq, where the architecture init_irq
    callback registers a syscon device, using a local variable for the
    regmap_config. As init_irq is very early in the platform bring up the
    regmap debugfs root isn't ready yet. Although this doesn't crash it
    does result in the debugfs entry not having the correct name.
    
    Regmap already sets map->name from config->name on the regmap_init
    path and the fact that a separate field is used to pass the name
    to regmap_debugfs_init appears to be an artifact of the debugfs
    name being added before the map name. As such this patch updates
    regmap_debugfs_init to use map->name, which is already duplicated from
    the config avoiding the issue.
    
    This does however leave two lose ends, both regmap_attach_dev and
    regmap_reinit_cache can be called after a regmap is registered and
    would have had the effect of applying a new name to the debugfs
    entries. In both of these cases it was chosen to update the map
    name. In the case of regmap_attach_dev there are 3 users that
    currently use this function to update the name, thus doing so avoids
    changes for those users and it seems reasonable that attaching
    a device would want to set the name of the map. In the case of
    regmap_reinit_cache the primary use-case appears to be devices that
    need some register access to identify the device (for example devices
    in the same family) and then update the cache to match the exact
    hardware. Whilst no users do currently update the name here, given the
    use-case it seemed reasonable the name might want to be updated once
    the device is better identified.
    Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20200917120828.12987-1-ckeepax@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
    94cc89eb
internal.h 8.17 KB