Re: fs/btrfs/extent-tree.c:8430:9: error: format not a string literal and no format arguments

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 20, 2013 at 10:05 AM, Jeff Mahoney <jeffm@xxxxxxxx> wrote:
> On 11/20/13, 12:30 PM, Chris Mason wrote:
>> Quoting Fengguang Wu (2013-11-19 23:05:51)
>>> On Tue, Nov 19, 2013 at 07:56:35PM -0800, Kees Cook wrote:
>>>> Hi!
>>>>
>>>> Which tree is 'devel-snb'? I don't see that on the kernel.org trees.
>>>
>>> It's my local merge branch, based on the latest upstream release.
>>>
>>> Let's CC the btrfs developers for this warning. :)
>>>
>>> Thanks,
>>> Fengguang
>>>
>>>> On Tue, Nov 19, 2013 at 5:01 PM, kbuild test robot
>>>> <fengguang.wu@xxxxxxxxx> wrote:
>>>>> tree:    devel-snb-x86_64-201311200240
>>>>> head:   1a985a0807ea34f37a4c5287089abd1cd2f65049
>>>>> commit: a9b93a3684dd6ebfb7cfa173f78a79c09de81207 Merge 'kees/format-security' into devel-snb-x86_64-201311200240
>>>>> date:   6 hours ago
>>>>> config: make ARCH=x86_64 allmodconfig
>>>>>
>>>>> All error/warnings:
>>>>>
>>>>>    fs/btrfs/extent-tree.c:6201:12: sparse: symbol 'get_raid_name' was not declared. Should it be static?
>>>>>    fs/btrfs/extent-tree.c:2469:28: sparse: context imbalance in 'run_clustered_refs' - unexpected unlock
>>>>>    fs/btrfs/extent-tree.c:8304:9: sparse: context imbalance in 'btrfs_put_block_group_cache' - wrong count at exit
>>>>>    fs/btrfs/extent-tree.c: In function '__link_block_group':
>>>>>>> fs/btrfs/extent-tree.c:8430:9: error: format not a string literal and no format arguments [-Werror=format-security]
>>>>>             get_raid_name(index));
>>
>> This comes from the btrfs-next tree, with Jeff's sysfs patches, so I've
>> added Jeff.

Ah, found it:
http://git.kernel.org/cgit/linux/kernel/git/josef/btrfs-next.git/tree/fs/btrfs/extent-tree.c

>
> Thanks for the heads up. I have a few other fixes that need to go into
> that patch set WRT cleanup too.

It looks like gcc is being stupid (const strings again). If you don't
want to change the call from

kobject_init_and_add(..., get_raid_name(index));

to

kobject_init_and_add(..., "%s", get_raid_name(index));

that's fine -- I can whitelist it since it's a string constant. But
since it's not critical path, it would be nice to gain the "%s" just
to be defensive if get_raid_name ever changes, etc.

Thanks for taking a look!

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux