linux-kernel - regd: sleeping in atomic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B9F86E9.2030702@gmail.com>
Date:	Tue, 16 Mar 2010 14:26:01 +0100
From:	Jiri Slaby <jirislaby@...il.com>
To:	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>
CC:	"John W. Linville" <linville@...driver.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: regd: sleeping in atomic

Hi,

Stanse found an atomic error in reg_copy_regd:

static int reg_copy_regd(const struct ieee80211_regdomain **dst_regd,
                          const struct ieee80211_regdomain *src_regd)
{
         struct ieee80211_regdomain *regd;
         int size_of_regd = 0;
         unsigned int i;

         size_of_regd = sizeof(struct ieee80211_regdomain) +
           ((src_regd->n_reg_rules + 1) * sizeof(struct 
ieee80211_reg_rule));

         regd = kzalloc(size_of_regd, GFP_KERNEL);       <---- here

Called from:

static void reg_regdb_search(struct work_struct *work)
{
         spin_lock(&reg_regdb_search_lock);
         while (!list_empty(&reg_regdb_search_list)) {
...
                 for (i=0; i<reg_regdb_size; i++) {
                         curdom = reg_regdb[i];

                         if (!memcmp(request->alpha2, curdom->alpha2, 2)) {
                                 r = reg_copy_regd(&regdom, curdom);
...
         spin_unlock(&reg_regdb_search_lock);
}

Whole error temporarily available at:
http://decibel.fi.muni.cz/~xslaby/stanse/error.cgi?db=34-rc&id=578

It is introduced by 3b377ea9d4efc94dc52fe41b4dfdb463635ab298.

Do you plan to extend it somehow or may the spinlock be converted to 
mutex? If not how much may size_of_regd be -- can we safely switch to 
GFP_ATOMIC?

-- 
js
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/