linux-kernel - Re: [PATCH] mm: fix lazy vmap purging (use-after-free error)

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <19f34abd0902211121i4eca3450y2c9306f73e23de7@mail.gmail.com>
Date:	Sat, 21 Feb 2009 20:21:22 +0100
From:	Vegard Nossum <vegard.nossum@...il.com>
To:	paulmck@...ux.vnet.ibm.com
Cc:	Ingo Molnar <mingo@...e.hu>, stable@...nel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Nick Piggin <npiggin@...e.de>,
	Pekka Enberg <penberg@...helsinki.fi>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: fix lazy vmap purging (use-after-free error)

2009/2/21 Paul E. McKenney <paulmck@...ux.vnet.ibm.com>:
> Is this behavior recent, or does it apply to earlier 2.6.29-rc kernels
> as well?  Does it happen with CONFIG_CLASSIC_RCU as well?  (From the
> trace above, I suspect that it might well do so, but if not, that will
> be valuable information as well.)

I don't know -- I haven't tried earlier kernels.

I just compiled a CONFIG_CLASSIC_RCU kernel, and it does happen there too:

[    1.061138] traversing list {
[    1.062281]     __free_vmap_area(c7803a40)
[    1.063177]     __free_vmap_area(c7803a80)
[    1.065217]     __free_vmap_area(c7803ac0)
[    1.066255]     __free_vmap_area(c7803b00)
[    1.067156]     kfree(c7803a40)
[    1.068292]     __free_vmap_area(c7803b40)
[    1.069094]     __free_vmap_area(c7803b80)
[    1.071051]     kfree(c7803a80)
[    1.072138]     __free_vmap_area(c7803bc0)
[    1.073101]     __free_vmap_area(c7803c00)
[    1.074065]     kfree(c7803ac0)
[    1.077126]     kfree(c7803b00)
[    1.078124]     __free_vmap_area(c7803c40)
[    1.079079]     __free_vmap_area(c7803c80)
...
[    4.645118]     __free_vmap_area(c7853440)
[    4.646099]     __free_vmap_area(c7853480)
[    4.646507]     __free_vmap_area(c78534c0)
[    4.647049]     kfree(c7853340)
[    4.648058]     kfree(c7853380)
[    4.650090] };
[    4.652061]     kfree(c78533c0)
[    4.653055]     kfree(c7853400)
[    4.656109]     kfree(c7853440)
[    4.656482]     kfree(c7853480)
[    4.656760]     kfree(c78534c0)
[    5.541885] traversing list {
[    5.543081]     __free_vmap_area(c7853380)
[    5.544071]     __free_vmap_area(c7853340)
...
[    8.977412]     __free_vmap_area(c7822400)
[    8.977723]     __free_vmap_area(c7822440)
[    8.978045]     kfree(c7822200)
[    8.978569]     kfree(c7822240)
[    8.979054]     kfree(c7822280)
[    8.979389] };
[    8.981051]     kfree(c78222c0)
[    8.983055]     kfree(c7822300)
[    8.984089]     kfree(c7822340)
[    8.984640] Freeing SMP alternatives: 20k freed
[    8.985146] ACPI: Core revision 20081204
[    8.986060]     kfree(c7822380)
[    8.987057]     kfree(c78223c0)
[    8.988052]     kfree(c7822400)
[    8.990045]     kfree(c7822440)
[    9.021526] ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1

The only difference I can see is that they're clumped together more
closely (4-5 calls of one kind, then 4-5 calls of the other) than with
the Tree RCU.


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
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/