[jira] [Updated] (TS-4252) Some plugins are causing seg-faults when using getopt_long with optind = 1.

["Peter Chou (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TS-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Chou updated TS-4252:
---------------------------
    Affects Version/s: 6.1.1
          Environment: Linux Intel 64-bit Ubuntu 14.04 and RHEL 7.
          Description: 
There are several global plugins which experience segmentation fault related to parsing (argc, argv) arguments using getopt_long(). Often, the plugins display debug output showing corrupted arguments, e.g., arguments belonging to previous entries in plugins.config. This has been confirmed to happen with background_fetch.so and regex_revalidate.so. The other plugins remap_stats and stale_while_revalidate may also be affected based on code review.

This issue is corrected if the plugins are modified to use optind = 0 instead of optind = 1 before calling getopt_long(). Note that the majority of plugins are using optind = 0 already. Per the Linux man page, you should only need to set optind = 1 between scanning different argument vectors, but you must set optind = 0 to cause some re-initialization to occur if you make use of GNU extensions in the opstring argument of getopt_long(). I am not sure if this applies to prior plugin using GNU extensions or current one (or going between one or the other), but it would seem safer to use optind = 0 always.

  was:
In "plugin.config" if we just do background_fetch.so with no arguments we get a segmentation fault with messages saying invalid option with argument text from previous lines in the configuration file. If I just add a garbage argument like "background_fetch.so bleah" there is no fault.

I noticed that this plugin initialized optind to 1 before calling getopt_long while others such as tcpinfo set it to 0. Setting it to 0 also prevents the fault. Is this the correct fix?

              Summary: Some plugins are causing seg-faults when using getopt_long with optind = 1.  (was: background_fetch.so segfaults with no arguments as a global plugin.)

Updated description to indicate multiple plugins affected.

> Some plugins are causing seg-faults when using getopt_long with optind = 1.
> ---------------------------------------------------------------------------
>
>                 Key: TS-4252
>                 URL: https://issues.apache.org/jira/browse/TS-4252
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Plugins
>    Affects Versions: 6.1.1
>         Environment: Linux Intel 64-bit Ubuntu 14.04 and RHEL 7.
>            Reporter: Peter Chou
>            Assignee: Leif Hedstrom
>             Fix For: 6.2.0
>
>
> There are several global plugins which experience segmentation fault related to parsing (argc, argv) arguments using getopt_long(). Often, the plugins display debug output showing corrupted arguments, e.g., arguments belonging to previous entries in plugins.config. This has been confirmed to happen with background_fetch.so and regex_revalidate.so. The other plugins remap_stats and stale_while_revalidate may also be affected based on code review.
> This issue is corrected if the plugins are modified to use optind = 0 instead of optind = 1 before calling getopt_long(). Note that the majority of plugins are using optind = 0 already. Per the Linux man page, you should only need to set optind = 1 between scanning different argument vectors, but you must set optind = 0 to cause some re-initialization to occur if you make use of GNU extensions in the opstring argument of getopt_long(). I am not sure if this applies to prior plugin using GNU extensions or current one (or going between one or the other), but it would seem safer to use optind = 0 always.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)