CVE-2009-2903: High severity linux kernel vulnerability
Memory leak in the appletalk subsystem in the Linux kernel 2.4.x through 2.4.37.6 and 2.6.x through 2.6.31, when the appletalk and ipddp modules are loaded but the ipddp"N" device is not found, allows remote attackers to cause a denial of service (memory consumption) via IP-DDP datagrams.
Other sources
Reported by Mark Smith: When the handleipoverddp() function checks for the "ipddp0" device and the device is not found, the function does not free the socket buffer structure (skb), leading to a memory leak. This only happens if you have the appletalk module loaded, but not the ipddp module, as this only happens when the "ipddp0" device does not exist.
For details see http://kbase.redhat.com/faq/docs/DOC-19077.
Analysis: call path: ltalkrcv -> atalkrcv -> handleipoverddp
net/appletalk/ddp.c: 1382 / 1383 atalkrcv - Receive a packet (in skb) from device dev 1384 @skb - packet received 1385 @dev - network device where the packet comes from 1386 @pt - packet type 1387 1388 Receive a packet (in skb) from device dev. This has come from the SNAP 1389 decoder, and on entry skb->transportheader is the DDP header, skb->len 1390 is the DDP header, skb->len is the DDP length. The physical headers 1391 have been extracted. PPP should probably pass frames marked as for this 1392 layer. [ie ARPHRDETHERTALK] 1393 / 1394 static int atalkrcv(struct skbuff skb, struct netdevice dev, 1395 struct packettype pt, struct netdevice origdev) 1396 { [...] 1456 / if IP over DDP is not selected this code will be optimized out / 1457 if (isipoverddp(skb)) 1458 return handleipoverddp(skb);
1267 static int handleipoverddp(struct skbuff skb) 1268 { 1269 struct netdevice dev = devgetbyname(&initnet, "ipddp0"); 1270 struct netdevicestats stats; 1271 1272 / This needs to be able to handle ipddp"N" devices / 1273 if (!dev) 1274 return -ENODEV; <-- did not call kfreeskb(skb) when the ipddp module is not loaded, and thus the device does not exist.
Also in linux-2.4.37.y: 1360 / 1361 Receive a packet (in skb) from device dev. This has come from the SNAP 1362 decoder, and on entry skb->h.raw is the DDP header, skb->len is the DDP 1363 header, skb->len is the DDP length. The physical headers have been 1364 extracted. PPP should probably pass frames marked as for this layer. 1365 [ie ARPHRDETHERTALK] 1366 / 1367 static int atalkrcv(struct skbuff skb, struct netdevice dev, 1368 struct packettype pt) 1369 { [...] 1496 #if defined(CONFIGIPDDP) || defined(CONFIGIPDDPMODULE) 1497 / Check if IP-over-DDP / 1498 if (skb->data[12] == 22) { 1499 struct netdevice dev = devgetbyname("ipddp0"); 1500 struct netdevicestats stats; 1501 1502 / This needs to be able to handle ipddp"N" devices / 1503 if (!dev) 1504 return -ENODEV; <-- did not call kfreeskb too [...] 1536 freeit: kfreeskb(skb); 1537 out: return 0; 1538 }
The patch also improved the aarpsendddp() function so that it handles failures and frees up of skb properly, rather than depending it on the caller.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
What is the severity of CVE-2009-2903?
CVE-2009-2903 is classified as a denial of service vulnerability due to a memory leak in the appletalk subsystem.
How do I fix CVE-2009-2903?
To fix CVE-2009-2903, update your Linux kernel to a version beyond 2.6.31 or 2.4.37.6.
What versions of Linux are affected by CVE-2009-2903?
CVE-2009-2903 affects Linux kernel versions 2.4.x up to 2.4.37.6 and 2.6.x up to 2.6.31.
Can CVE-2009-2903 be exploited remotely?
Yes, CVE-2009-2903 can be exploited remotely via IP-DDP datagrams.
What is the impact of exploiting CVE-2009-2903?
Exploiting CVE-2009-2903 can lead to denial of service due to increased memory consumption.