LWN.net Weekly Edition for October 4, 2007

Yet another male perspective on women in free software

O'Reilly has been running a series of articles on women in technology which has an emphasis on encouraging women to enter the field. LWN has, in its usual way, posted pointers to a subset of those articles; most of those pointers have resulted in lengthy conversations among LWN readers. Those readers, true to their usual form, have managed to hold a higher-level discussion than has been seen in other forums. That said, there have been a lot of bits expended on discussions of topics like relative brain sizes, differing approaches to family life, the true femininity of transsexuals, and so on. Your editor, not generally known for being short of opinions, could expound on many of these topics, but that is not going to happen here. Such discussions are not really relevant to the topic at hand.

The relevant discussion, it seems, can be much more simple and straightforward, concentrating on a few basic points:

• The participation by women in the free software community is strikingly low. It is not just far below the incidence of women in the wider world; it is also well below the percentage of women found in more traditional technical jobs.

• We would be better off if we could attract more women to our community. We are not so rich that we can afford to do without skilled developers, writers, artists, project managers, and so on. We are not so diverse that we can afford to do without a wider variety of points of view.

• We, as a community, behave in ways which drive women away. We are also good at repelling people with thin skins, people with different cultural expectations on how professionals talk to each other, and anybody else who does not easily fit in.

There is no need to get drawn into blind alleys about genetic links to mathematical ability or the demands of family life. There is no point in being distracted by strawmen, be they an outspoken feminist that somebody finds particularly obnoxious or the notion that somebody is calling for a quota of 50% female participation. There is no shortage of incredibly smart, talented, and interested women out there who have found our community unwelcoming; that, on its own terms, is a problem.

When comments (not on LWN, happily) respond to this year's kernel summit group photo by comparing the relative merits of the few female developers found there, our community as a whole becomes that much more hostile. When certain Linux publications run overtly demeaning ads, a clear view of how women should participate in free software is being communicated. When sexist idiots drive one of the most humorous and human diaries off the net, we all lose out. When well-intentioned commenters employ terms like "sausage fest," they show that we still clearly miss the point. When women are harassed at Linux events, there is a good chance that they will not come back. And when all of these things (and worse) drive people out of our community, we are all impoverished as a result.

Making things better does not require the establishment of some sort of police force to enforce extensive rules. We do not need to replicate Gentoo's "proctors" experiment. We do not have to establish official codes of conduct, though making it clear that a certain level of polite and respectful behavior is expected cannot hurt. But if we can recognize the problem - that our community's behavior is driving away women and many other potential contributors - without trying to bury it in irrelevant strawman arguments, we will be off to a good start. We are, as a community, good at solving problems once we realize that they need our attention. This one needs our attention.

Comments (79 posted)

Matt Domsch on Linux support at Dell

Curious about the state of Linux support at Dell, we asked Matt Domsch, Linux Technology Strategist there, some questions by email. Matt has been working to support Linux on Dell hardware for eight years and has broad knowledge of the kinds of issues hardware vendors face when supporting Linux. He was gracious enough to answer our questions at length, covering some history, challenges and the future for Linux at Dell.

LWN: Can you give us an overview of your Linux history? When did you get involved with Linux and why?

LWN: What is your history at Dell? And the history of Linux support at Dell?

LWN: What have been the biggest challenges with supporting Linux at Dell?

[PULL QUOTE: Dell expects our partner hardware vendors to provide fully open source / free software drivers, and to maintain them in the appropriate upstream project, kernel.org or x.org. This has been our policy since we started shipping Linux on servers in 1999, and continues to be our policy today. END QUOTE] LWN: Does Dell have plans to make hardware changes in the future to support more hardware with free drivers, specifically video and wireless cards?

LWN: You folks recently made a new version of Ubuntu with updated drivers and the like, can you give us an idea of what the aim of that effort was? What kind of problems were you trying to solve and what plans do you have to work with Ubuntu to avoid that in the future?

LWN: Can you tell us about the testing and support lab at Dell?

LWN: What is DKMS? What's the status of the project? What still remains to be done?

LWN: Where do you see Linux at Dell heading? More systems supported, more distributions supported, or other things entirely?

Our thanks to Matt for taking the time to respond in detail.

Comments (21 posted)

Memory part 2: CPU caches

[Editor's note: This is the second installment in Ulrich Drepper's "What every programmer should know about memory" document. Those who have not read the first part will likely want to start there. This is good stuff, and we once again thank Ulrich for allowing us to publish it.

One quick request: in a document of this length there are bound to be a few typographical errors remaining. If you find one, and wish to see it corrected, please let us know via mail to lwn@lwn.net rather than by posting a comment. That way we will be sure to incorporate the fix and get it back into Ulrich's copy of the document and other readers will not have to plow through uninteresting comments.]

CPUs are today much more sophisticated than they were only 25 years ago. In those days, the frequency of the CPU core was at a level equivalent to that of the memory bus. Memory access was only a bit slower than register access. But this changed dramatically in the early 90s, when CPU designers increased the frequency of the CPU core but the frequency of the memory bus and the performance of RAM chips did not increase proportionally. This is not due to the fact that faster RAM could not be built, as explained in the previous section. It is possible but it is not economical. RAM as fast as current CPU cores is orders of magnitude more expensive than any dynamic RAM.

If the choice is between a machine with very little, very fast RAM and a machine with a lot of relatively fast RAM, the second will always win given a working set size which exceeds the small RAM size and the cost of accessing secondary storage media such as hard drives. The problem here is the speed of secondary storage, usually hard disks, which must be used to hold the swapped out part of the working set. Accessing those disks is orders of magnitude slower than even DRAM access.

Fortunately it does not have to be an all-or-nothing decision. A computer can have a small amount of high-speed SRAM in addition to the large amount of DRAM. One possible implementation would be to dedicate a certain area of the address space of the processor as containing the SRAM and the rest the DRAM. The task of the operating system would then be to optimally distribute data to make use of the SRAM. Basically, the SRAM serves in this situation as an extension of the register set of the processor.

While this is a possible implementation, it is not viable. Ignoring the problem of mapping the physical resources of such SRAM-backed memory to the virtual address spaces of the processes (which by itself is terribly hard) this approach would require each process to administer in software the allocation of this memory region. The size of the memory region can vary from processor to processor (i.e., processors have different amounts of the expensive SRAM-backed memory). Each module which makes up part of a program will claim its share of the fast memory, which introduces additional costs through synchronization requirements. In short, the gains of having fast memory would be eaten up completely by the overhead of administering the resources.

So, instead of putting the SRAM under the control of the OS or user, it becomes a resource which is transparently used and administered by the processors. In this mode, SRAM is used to make temporary copies of (to cache, in other words) data in main memory which is likely to be used soon by the processor. This is possible because program code and data has temporal and spatial locality. This means that, over short periods of time, there is a good chance that the same code or data gets reused. For code this means that there are most likely loops in the code so that the same code gets executed over and over again (the perfect case for spatial locality). Data accesses are also ideally limited to small regions. Even if the memory used over short time periods is not close together there is a high chance that the same data will be reused before long (temporal locality). For code this means, for instance, that in a loop a function call is made and that function is located elsewhere in the address space. The function may be distant in memory, but calls to that function will be close in time. For data it means that the total amount of memory used at one time (the working set size) is ideally limited but the memory used, as a result of the random access nature of RAM, is not close together. Realizing that locality exists is key to the concept of CPU caches as we use them today.

A simple computation can show how effective caches can theoretically be. Assume access to main memory takes 200 cycles and access to the cache memory take 15 cycles. Then code using 100 data elements 100 times each will spend 2,000,000 cycles on memory operations if there is no cache and only 168,500 cycles if all data can be cached. That is an improvement of 91.5%.

The size of the SRAM used for caches is many times smaller than the main memory. In the author's experience with workstations with CPU caches the cache size has always been around 1/1000th of the size of the main memory (today: 4MB cache and 4GB main memory). This alone does not constitute a problem. If the size of the working set (the set of data currently worked on) is smaller than the cache size it does not matter. But computers do not have large main memories for no reason. The working set is bound to be larger than the cache. This is especially true for systems running multiple processes where the size of the working set is the sum of the sizes of all the individual processes and the kernel.

What is needed to deal with the limited size of the cache is a set of good strategies to determine what should be cached at any given time. Since not all data of the working set is used at exactly the same time we can use techniques to temporarily replace some data in the cache with other data. And maybe this can be done before the data is actually needed. This prefetching would remove some of the costs of accessing main memory since it happens asynchronously with respect to the execution of the program. All these techniques and more can be used to make the cache appear bigger than it actually is. We will discuss them in Section 3.3. Once all these techniques are exploited it is up to the programmer to help the processor. How this can be done will be discussed in Section 6.

3.1 CPU Caches in the Big Picture

Before diving into technical details of the implementation of CPU caches some readers might find it useful to first see in some more details how caches fit into the “big picture” of a modern computer system.

Figure 3.1: Minimum Cache Configuration

Figure 3.1 shows the minimum cache configuration. It corresponds to the architecture which could be found in early systems which deployed CPU caches. The CPU core is no longer directly connected to the main memory. {In even earlier systems the cache was attached to the system bus just like the CPU and the main memory. This was more a hack than a real solution.} All loads and stores have to go through the cache. The connection between the CPU core and the cache is a special, fast connection. In a simplified representation, the main memory and the cache are connected to the system bus which can also be used for communication with other components of the system. We introduced the system bus as “FSB” which is the name in use today; see Section 2.2. In this section we ignore the Northbridge; it is assumed to be present to facilitate the communication of the CPU(s) with the main memory.

Even though computers for the last several decades have used the von Neumann architecture, experience has shown that it is of advantage to separate the caches used for code and for data. Intel has used separate code and data caches since 1993 and never looked back. The memory regions needed for code and data are pretty much independent of each other, which is why independent caches work better. In recent years another advantage emerged: the instruction decoding step for the most common processors is slow; caching decoded instructions can speed up the execution, especially when the pipeline is empty due to incorrectly predicted or impossible-to-predict branches.

Soon after the introduction of the cache, the system got more complicated. The speed difference between the cache and the main memory increased again, to a point that another level of cache was added, bigger and slower than the first-level cache. Only increasing the size of the first-level cache was not an option for economical reasons. Today, there are even machines with three levels of cache in regular use. A system with such a processor looks like Figure 3.2. With the increase on the number of cores in a single CPU the number of cache levels might increase in the future even more.

Figure 3.2: Processor with Level 3 Cache

Figure 3.2 shows three levels of cache and introduces the nomenclature we will use in the remainder of the document. L1d is the level 1 data cache, L1i the level 1 instruction cache, etc. Note that this is a schematic; the data flow in reality need not pass through any of the higher-level caches on the way from the core to the main memory. CPU designers have a lot of freedom designing the interfaces of the caches. For programmers these design choices are invisible.

In addition we have processors which have multiple cores and each core can have multiple “threads”. The difference between a core and a thread is that separate cores have separate copies of (almost {Early multi-core processors even had separate 2^nd level caches and no 3^rd level cache.}) all the hardware resources. The cores can run completely independently unless they are using the same resources—e.g., the connections to the outside—at the same time. Threads, on the other hand, share almost all of the processor's resources. Intel's implementation of threads has only separate registers for the threads and even that is limited, some registers are shared. The complete picture for a modern CPU therefore looks like Figure 3.3.

Figure 3.3: Multi processor, multi-core, multi-thread

In this figure we have two processors, each with two cores, each of which has two threads. The threads share the Level 1 caches. The cores (shaded in the darker gray) have individual Level 1 caches. All cores of the CPU share the higher-level caches. The two processors (the two big boxes shaded in the lighter gray) of course do not share any caches. All this will be important, especially when we are discussing the cache effects on multi-process and multi-thread applications.

3.2 Cache Operation at High Level

To understand the costs and savings of using a cache we have to combine the knowledge about the machine architecture and RAM technology from Section 2 with the structure of caches described in the previous section.

By default all data read or written by the CPU cores is stored in the cache. There are memory regions which cannot be cached but this is something only the OS implementers have to be concerned about; it is not visible to the application programmer. There are also instructions which allow the programmer to deliberately bypass certain caches. This will be discussed in Section 6.

If the CPU needs a data word the caches are searched first. Obviously, the cache cannot contain the content of the entire main memory (otherwise we would need no cache), but since all memory addresses are cacheable, each cache entry is tagged using the address of the data word in the main memory. This way a request to read or write to an address can search the caches for a matching tag. The address in this context can be either the virtual or physical address, varying based on the cache implementation.

Since the tag requires space in addition to the actual memory, it is inefficient to chose a word as the granularity of the cache. For a 32-bit word on an x86 machine the tag itself might need 32 bits or more. Furthermore, since spatial locality is one of the principles on which caches are based, it would be bad to not take this into account. Since neighboring memory is likely to be used together it should also be loaded into the cache together. Remember also what we learned in Section 2.2.1: RAM modules are much more effective if they can transport many data words in a row without a new CAS or even RAS signal. So the entries stored in the caches are not single words but, instead, “lines” of several contiguous words. In early caches these lines were 32 bytes long; now the norm is 64 bytes. If the memory bus is 64 bits wide this means 8 transfers per cache line. DDR supports this transport mode efficiently.

When memory content is needed by the processor the entire cache line is loaded into the L1d. The memory address for each cache line is computed by masking the address value according to the cache line size. For a 64 byte cache line this means the low 6 bits are zeroed. The discarded bits are used as the offset into the cache line. The remaining bits are in some cases used to locate the line in the cache and as the tag. In practice an address value is split into three parts. For a 32-bit address it might look as follows:

With a cache line size of 2^O the low O bits are used as the offset into the cache line. The next S bits select the “cache set”. We will go into more detail soon on why sets, and not single slots, are used for cache lines. For now it is sufficient to understand there are 2^S sets of cache lines. This leaves the top 32 - S - O = T bits which form the tag. These T bits are the value associated with each cache line to distinguish all the aliases {All cache lines with the same S part of the address are known by the same alias.} which are cached in the same cache set. The S bits used to address the cache set do not have to be stored since they are the same for all cache lines in the same set.

When an instruction modifies memory the processor still has to load a cache line first because no instruction modifies an entire cache line at once (exception to the rule: write-combining as explained in Section 6.1). The content of the cache line before the write operation therefore has to be loaded. It is not possible for a cache to hold partial cache lines. A cache line which has been written to and which has not been written back to main memory is said to be “dirty”. Once it is written the dirty flag is cleared.

To be able to load new data in a cache it is almost always first necessary to make room in the cache. An eviction from L1d pushes the cache line down into L2 (which uses the same cache line size). This of course means room has to be made in L2. This in turn might push the content into L3 and ultimately into main memory. Each eviction is progressively more expensive. What is described here is the model for an exclusive cache as is preferred by modern AMD and VIA processors. Intel implements inclusive caches {This generalization is not completely correct. A few caches are exclusive and some inclusive caches have exclusive cache properties.} where each cache line in L1d is also present in L2. Therefore evicting from L1d is much faster. With enough L2 cache the disadvantage of wasting memory for content held in two places is minimal and it pays off when evicting. A possible advantage of an exclusive cache is that loading a new cache line only has to touch the L1d and not the L2, which could be faster.

The CPUs are allowed to manage the caches as they like as long as the memory model defined for the processor architecture is not changed. It is, for instance, perfectly fine for a processor to take advantage of little or no memory bus activity and proactively write dirty cache lines back to main memory. The wide variety of cache architectures among the processors for the x86 and x86-64, between manufacturers and even within the models of the same manufacturer, are testament to the power of the memory model abstraction.

In symmetric multi-processor (SMP) systems the caches of the CPUs cannot work independently from each other. All processors are supposed to see the same memory content at all times. The maintenance of this uniform view of memory is called “cache coherency”. If a processor were to look simply at its own caches and main memory it would not see the content of dirty cache lines in other processors. Providing direct access to the caches of one processor from another processor would be terribly expensive and a huge bottleneck. Instead, processors detect when another processor wants to read or write to a certain cache line.

If a write access is detected and the processor has a clean copy of the cache line in its cache, this cache line is marked invalid. Future references will require the cache line to be reloaded. Note that a read access on another CPU does not necessitate an invalidation, multiple clean copies can very well be kept around.

More sophisticated cache implementations allow another possibility to happen. If the cache line which another processor wants to read from or write to is currently marked dirty in the first processor's cache a different course of action is needed. In this case the main memory is out-of-date and the requesting processor must, instead, get the cache line content from the first processor. Through snooping, the first processor notices this situation and automatically sends the requesting processor the data. This action bypasses main memory, though in some implementations the memory controller is supposed to notice this direct transfer and store the updated cache line content in main memory. If the access is for writing the first processor then invalidates its copy of the local cache line.

Over time a number of cache coherency protocols have been developed. The most important is MESI, which we will introduce in Section 3.3.4. The outcome of all this can be summarized in a few simple rules:

• A dirty cache line is not present in any other processor's cache.

• Clean copies of the same cache line can reside in arbitrarily many caches.

If these rules can be maintained, processors can use their caches efficiently even in multi-processor systems. All the processors need to do is to monitor each others' write accesses and compare the addresses with those in their local caches. In the next section we will go into a few more details about the implementation and especially the costs.

Finally, we should at least give an impression of the costs associated with cache hits and misses. These are the numbers Intel lists for a Pentium M:

To Where	Cycles
Register	<= 1
L1d	~3
L2	~14
Main Memory	~240

These are the actual access times measured in CPU cycles. It is interesting to note that for the on-die L2 cache a large part (probably even the majority) of the access time is caused by wire delays. This is a physical limitation which can only get worse with increasing cache sizes. Only process shrinking (for instance, going from 60nm for Merom to 45nm for Penryn in Intel's lineup) can improve those numbers.

The numbers in the table look high but, fortunately, the entire cost does not have to be paid for each occurrence of the cache load and miss. Some parts of the cost can be hidden. Today's processors all use internal pipelines of different lengths where the instructions are decoded and prepared for execution. Part of the preparation is loading values from memory (or cache) if they are transferred to a register. If the memory load operation can be started early enough in the pipeline, it may happen in parallel with other operations and the entire cost of the load might be hidden. This is often possible for L1d; for some processors with long pipelines for L2 as well.

There are many obstacles to starting the memory read early. It might be as simple as not having sufficient resources for the memory access or it might be that the final address of the load becomes available late as the result of another instruction. In these cases the load costs cannot be hidden (completely).

For write operations the CPU does not necessarily have to wait until the value is safely stored in memory. As long as the execution of the following instructions appears to have the same effect as if the value were stored in memory there is nothing which prevents the CPU from taking shortcuts. It can start executing the next instruction early. With the help of shadow registers which can hold values no longer available in a regular register it is even possible to change the value which is to be stored in the incomplete write operation.

Figure 3.4: Access Times for Random Writes

For an illustration of the effects of cache behavior see Figure 3.4. We will talk about the program which generated the data later; it is a simple simulation of a program which accesses a configurable amount of memory repeatedly in a random fashion. Each data item has a fixed size. The number of elements depends on the selected working set size. The Y–axis shows the average number of CPU cycles it takes to process one element; note that the scale for the Y–axis is logarithmic. The same applies in all the diagrams of this kind to the X–axis. The size of the working set is always shown in powers of two.

The graph shows three distinct plateaus. This is not surprising: the specific processor has L1d and L2 caches, but no L3. With some experience we can deduce that the L1d is 2¹³ bytes in size and that the L2 is 2²⁰ bytes in size. If the entire working set fits into the L1d the cycles per operation on each element is below 10. Once the L1d size is exceeded the processor has to load data from L2 and the average time springs up to around 28. Once the L2 is not sufficient anymore the times jump to 480 cycles and more. This is when many or most operations have to load data from main memory. And worse: since data is being modified dirty cache lines have to be written back, too.

This graph should give sufficient motivation to look into coding improvements which help improve cache usage. We are not talking about a few measly percent here; we are talking about orders-of-magnitude improvements which are sometimes possible. In Section 6 we will discuss techniques which allow writing more efficient code. The next section goes into more details of CPU cache designs. The knowledge is good to have but not necessary for the rest of the paper. So this section could be skipped.

3.3 CPU Cache Implementation Details

Cache implementers have the problem that each cell in the huge main memory potentially has to be cached. If the working set of a program is large enough this means there are many main memory locations which fight for each place in the cache. Previously it was noted that a ratio of 1-to-1000 for cache versus main memory size is not uncommon.

3.3.1 Associativity

It would be possible to implement a cache where each cache line can hold a copy of any memory location. This is called a fully associative cache. To access a cache line the processor core would have to compare the tags of each and every cache line with the tag for the requested address. The tag would be comprised of the entire part of the address which is not the offset into the cache line (that means, S in the figure on Section 3.2 is zero).

There are caches which are implemented like this but, by looking at the numbers for an L2 in use today, will show that this is impractical. Given a 4MB cache with 64B cache lines the cache would have 65,536 entries. To achieve adequate performance the cache logic would have to be able to pick from all these entries the one matching a given tag in just a few cycles. The effort to implement this would be enormous.

Figure 3.5: Fully Associative Cache Schematics

For each cache line a comparator is needed to compare the large tag (note, S is zero). The letter next to each connection indicates the width in bits. If none is given it is a single bit line. Each comparator has to compare two T-bit-wide values. Then, based on the result, the appropriate cache line content is selected and made available. This requires merging as many sets of O data lines as there are cache buckets. The number of transistors needed to implement a single comparator is large especially since it must work very fast. No iterative comparator is usable. The only way to save on the number of comparators is to reduce the number of them by iteratively comparing the tags. This is not suitable for the same reason that iterative comparators are not: it takes too long.

Fully associative caches are practical for small caches (for instance, the TLB caches on some Intel processors are fully associative) but those caches are small, really small. We are talking about a few dozen entries at most.

For L1i, L1d, and higher level caches a different approach is needed. What can be done is to restrict the search. In the most extreme restriction each tag maps to exactly one cache entry. The computation is simple: given the 4MB/64B cache with 65,536 entries we can directly address each entry by using bits 6 to 21 of the address (16 bits). The low 6 bits are the index into the cache line.

Figure 3.6: Direct-Mapped Cache Schematics

Such a direct-mapped cache is fast and relatively easy to implement as can be seen in Figure 3.6. It requires exactly one comparator, one multiplexer (two in this diagram where tag and data are separated, but this is not a hard requirement on the design), and some logic to select only valid cache line content. The comparator is complex due to the speed requirements but there is only one of them now; as a result more effort can be spent on making it fast. The real complexity in this approach lies in the multiplexers. The number of transistors in a simple multiplexer grows with O(log N), where N is the number of cache lines. This is tolerable but might get slow, in which case speed can be increased by spending more real estate on transistors in the multiplexers to parallelize some of the work and to increase the speed. The total number of transistors can grow slowly with a growing cache size which makes this solution very attractive. But it has a drawback: it only works well if the addresses used by the program are evenly distributed with respect to the bits used for the direct mapping. If they are not, and this is usually the case, some cache entries are heavily used and therefore repeatedly evicted while others are hardly used at all or remain empty.

Figure 3.7: Set-Associative Cache Schematics

This problem can be solved by making the cache set associative. A set-associative cache combines the features of the full associative and direct-mapped caches to largely avoid the weaknesses of those designs. Figure 3.7 shows the design of a set-associative cache. The tag and data storage are divided into sets which are selected by the address. This is similar to the direct-mapped cache. But instead of only having one element for each set value in the cache a small number of values is cached for the same set value. The tags for all the set members are compared in parallel, which is similar to the functioning of the fully associative cache.

The result is a cache which is not easily defeated by unfortunate or deliberate selection of addresses with the same set numbers and at the same time the size of the cache is not limited by the number of comparators which can be implemented in parallel. If the cache grows it is (in this figure) only the number of columns which increases, not the number of rows. The number of rows only increases if the associativity of the cache is increased. Today processors are using associativity levels of up to 16 for L2 caches or higher. L1 caches usually get by with 8.

L2 Cache Size	Associativity
	Direct		2		4		8
	CL=32	CL=64	CL=32	CL=64	CL=32	CL=64	CL=32	CL=64
512k	27,794,595	20,422,527	25,222,611	18,303,581	24,096,510	17,356,121	23,666,929	17,029,334
1M	19,007,315	13,903,854	16,566,738	12,127,174	15,537,500	11,436,705	15,162,895	11,233,896
2M	12,230,962	8,801,403	9,081,881	6,491,011	7,878,601	5,675,181	7,391,389	5,382,064
4M	7,749,986	5,427,836	4,736,187	3,159,507	3,788,122	2,418,898	3,430,713	2,125,103
8M	4,731,904	3,209,693	2,690,498	1,602,957	2,207,655	1,228,190	2,111,075	1,155,847
16M	2,620,587	1,528,592	1,958,293	1,089,580	1,704,878	883,530	1,671,541	862,324

Table 3.1: Effects of Cache Size, Associativity, and Line Size

Given our 4MB/64B cache and 8-way set associativity the cache we are left with has 8,192 sets and only 13 bits of the tag are used in addressing the cache set. To determine which (if any) of the entries in the cache set contains the addressed cache line 8 tags have to be compared. That is feasible to do in very short time. With an experiment we can see that this makes sense.

Table 3.1 shows the number of L2 cache misses for a program (gcc in this case, the most important benchmark of them all, according to the Linux kernel people) for changing cache size, cache line size, and associativity set size. In Section 7.2 we will introduce the tool to simulate the caches as required for this test.

Just in case this is not yet obvious, the relationship of all these values is that the cache size is

cache line size × associativity × number of sets

The addresses are mapped into the cache by using

O = log₂ cache line size
S = log₂ number of sets

in the way the figure in Section 3.2 shows.

Figure 3.8: Cache Size vs Associativity (CL=32)

Figure 3.8 makes the data of the table more comprehensible. It shows the data for a fixed cache line size of 32 bytes. Looking at the numbers for a given cache size we can see that associativity can indeed help to reduce the number of cache misses significantly. For an 8MB cache going from direct mapping to 2-way set associative cache saves almost 44% of the cache misses. The processor can keep more of the working set in the cache with a set associative cache compared with a direct mapped cache.

In the literature one can occasionally read that introducing associativity has the same effect as doubling cache size. This is true in some extreme cases as can be seen in the jump from the 4MB to the 8MB cache. But it certainly is not true for further doubling of the associativity. As we can see in the data, the successive gains are much smaller. We should not completely discount the effects, though. In the example program the peak memory use is 5.6M. So with a 8MB cache there are unlikely to be many (more than two) uses for the same cache set. With a larger working set the savings can be higher as we can see from the larger benefits of associativity for the smaller cache sizes.

In general, increasing the associativity of a cache above 8 seems to have little effects for a single-thread workload. With the introduction of multi-core processors which use a shared L2 the situation changes. Now you basically have two programs hitting on the same cache which causes the associativity in practice to be halved (or quartered for quad-core processors). So it can be expected that, with increasing numbers of cores, the associativity of the shared caches should grow. Once this is not possible anymore (16-way set associativity is already hard) processor designers have to start using shared L3 caches and beyond, while L2 caches are potentially shared by a subset of the cores.

Another effect we can study in Figure 3.8 is how the increase in cache size helps with performance. This data cannot be interpreted without knowing about the working set size. Obviously, a cache as large as the main memory would lead to better results than a smaller cache, so there is in general no limit to the largest cache size with measurable benefits.

As already mentioned above, the size of the working set at its peak is 5.6M. This does not give us any absolute number of the maximum beneficial cache size but it allows us to estimate the number. The problem is that not all the memory used is contiguous and, therefore, we have, even with a 16M cache and a 5.6M working set, conflicts (see the benefit of the 2-way set associative 16MB cache over the direct mapped version). But it is a safe bet that with the same workload the benefits of a 32MB cache would be negligible. But who says the working set has to stay the same? Workloads are growing over time and so should the cache size. When buying machines, and one has to choose the cache size one is willing to pay for, it is worthwhile to measure the working set size. Why this is important can be seen in the figures on Figure 3.10.

Figure 3.9: Test Memory Layouts

Two types of tests are run. In the first test the elements are processed sequentially. The test program follows the pointer n but the array elements are chained so that they are traversed in the order in which they are found in memory. This can be seen in the lower part of Figure 3.9. There is one back reference from the last element. In the second test (upper part of the figure) the array elements are traversed in a random order. In both cases the array elements form a circular single-linked list.

3.3.2 Measurements of Cache Effects

All the figures are created by measuring a program which can simulate working sets of arbitrary size, read and write access, and sequential or random access. We have already seen some results in Figure 3.4. The program creates an array corresponding to the working set size of elements of this type:

  struct l {
    struct l *n;
    long int pad[NPAD];
  };

All entries are chained in a circular list using the n element, either in sequential or random order. Advancing from one entry to the next always uses the pointer, even if the elements are laid out sequentially. The pad element is the payload and it can grow arbitrarily large. In some tests the data is modified, in others the program only performs read operations.

In the performance measurements we are talking about working set sizes. The working set is made up of an array of struct l elements. A working set of 2^N bytes contains

2^N/sizeof(struct l)

elements. Obviously sizeof(struct l) depends on the value of NPAD. For 32-bit systems, NPAD=7 means the size of each array element is 32 bytes, for 64-bit systems the size is 64 bytes.

Single Threaded Sequential Access

The simplest case is a simple walk over all the entries in the list. The list elements are laid out sequentially, densely packed. Whether the order of processing is forward or backward does not matter, the processor can deal with both directions equally well. What we measure here—and in all the following tests—is how long it takes to handle a single list element. The time unit is a processor cycle. Figure 3.10 shows the result. Unless otherwise specified, all measurements are made on a Pentium 4 machine in 64-bit mode which means the structure l with NPAD=0 is eight bytes in size.

Figure 3.10: Sequential Read Access, NPAD=0

Figure 3.11: Sequential Read for Several Sizes

The first two measurements are polluted by noise. The measured workload is simply too small to filter the effects of the rest of the system out. We can safely assume that the values are all at the 4 cycles level. With this in mind we can see three distinct levels:

• Up to a working set size of 2¹⁴ bytes.

• From 2¹⁵ bytes to 2²⁰ bytes.

• From 2²¹ bytes and up.

These steps can be easily explained: the processor has a 16kB L1d and 1MB L2. We do not see sharp edges in the transition from one level to the other because the caches are used by other parts of the system as well and so the cache is not exclusively available for the program data. Specifically the L2 cache is a unified cache and also used for the instructions (NB: Intel uses inclusive caches).

What is perhaps not quite expected are the actual times for the different working set sizes. The times for the L1d hits are expected: load times after an L1d hit are around 4 cycles on the P4. But what about the L2 accesses? Once the L1d is not sufficient to hold the data one might expect it would take 14 cycles or more per element since this is the access time for the L2. But the results show that only about 9 cycles are required. This discrepancy can be explained by the advanced logic in the processors. In anticipation of using consecutive memory regions, the processor prefetches the next cache line. This means that when the next line is actually used it is already halfway loaded. The delay required to wait for the next cache line to be loaded is therefore much less than the L2 access time.

The effect of prefetching is even more visible once the working set size grows beyond the L2 size. Before we said that a main memory access takes 200+ cycles. Only with effective prefetching is it possible for the processor to keep the access times as low as 9 cycles. As we can see from the difference between 200 and 9, this works out nicely.

We can observe the processor while prefetching, at least indirectly. In Figure 3.11 we see the times for the same working set sizes but this time we see the graphs for different sizes of the structure l. This means we have fewer but larger elements in the list. The different sizes have the effect that the distance between the n elements in the (still consecutive) list grows. In the four cases of the graph the distance is 0, 56, 120, and 248 bytes respectively.

At the bottom we can see the line from the previous graph, but this time it appears more or less as a flat line. The times for the other cases are simply so much worse. We can see in this graph, too, the three different levels and we see the large errors in the tests with the small working set sizes (ignore them again). The lines more or less all match each other as long as only the L1d is involved. There is no prefetching necessary so all element sizes just hit the L1d for each access.

For the L2 cache hits we see that the three new lines all pretty much match each other but that they are at a higher level (about 28). This is the level of the access time for the L2. This means prefetching from L2 into L1d is basically disabled. Even with NPAD=7 we need a new cache line for each iteration of the loop; for NPAD=0, instead, the loop has to iterate eight times before the next cache line is needed. The prefetch logic cannot load a new cache line every cycle. Therefore we see a stall to load from L2 in every iteration.

It gets even more interesting once the working set size exceeds the L2 capacity. Now all four lines vary widely. The different element sizes play obviously a big role in the difference in performance. The processor should recognize the size of the strides and not fetch unnecessary cache lines for NPAD=15 and 31 since the element size is smaller than the prefetch window (see Section 6.3.1). Where the element size is hampering the prefetching efforts is a result of a limitation of hardware prefetching: it cannot cross page boundaries. We are reducing the effectiveness of the hardware scheduler by 50% for each size increase. If the hardware prefetcher were allowed to cross page boundaries and the next page is not resident or valid the OS would have to get involved in locating the page. That means the program would experience a page fault it did not initiate itself. This is completely unacceptable since the processor does not know whether a page is not present or does not exist. In the latter case the OS would have to abort the process. In any case, given that, for NPAD=7 and higher, we need one cache line per list element the hardware prefetcher cannot do much. There simply is no time to load the data from memory since all the processor does is read one word and then load the next element.

Another big reason for the slowdown are the misses of the TLB cache. This is a cache where the results of the translation of a virtual address to a physical address are stored, as is explained in more detail in Section 4. The TLB cache is quite small since it has to be extremely fast. If more pages are accessed repeatedly than the TLB cache has entries for the translation from virtual to physical address has to be constantly repeated. This is a very costly operation. With larger element sizes the cost of a TLB lookup is amortized over fewer elements. That means the total number of TLB entries which have to be computed per list element is higher.

To observe the TLB effects we can run a different test. For one measurement we lay out the elements sequentially as usual. We use NPAD=7 for elements which occupy one entire cache line. For the second measurement we place each list element on a separate page. The rest of each page is left untouched and we do not count it in the total for the working set size. {Yes, this is a bit inconsistent because in the other tests we count the unused part of the struct in the element size and we could define NPAD so that each element fills a page. In that case the working set sizes would be very different. This is not the point of this test, though, and since prefetching is ineffective anyway this makes little difference.} The consequence is that, for the first measurement, each list iteration requires a new cache line and, for every 64 elements, a new page. For the second measurement each iteration requires loading a new cache line which is on a new page.

Figure 3.12: TLB Influence for Sequential Read

The result can be seen in Figure 3.12. The measurements were performed on the same machine as Figure 3.11. Due to limitations of the available RAM the working set size had to be restricted to 2²⁴ bytes which requires 1GB to place the objects on separate pages. The lower, red curve corresponds exactly to the NPAD=7 curve in Figure 3.11. We see the distinct steps showing the sizes of the L1d and L2 caches. The second curve looks radically different. The important feature is the huge spike starting when the working set size reaches 2¹³ bytes. This is when the TLB cache overflows. With an element size of 64 bytes we can compute that the TLB cache has 64 entries. There are no page faults affecting the cost since the program locks the memory to prevent it from being swapped out.

As can be seen the number of cycles it takes to compute the physical address and store it in the TLB is very high. The graph in Figure 3.12 shows the extreme case, but it should now be clear that a significant factor in the slowdown for larger NPAD values is the reduced efficiency of the TLB cache. Since the physical address has to be computed before a cache line can be read for either L2 or main memory the address translation penalties are additive to the memory access times. This in part explains why the total cost per list element for NPAD=31 is higher than the theoretical access time for the RAM.

Figure 3.13: Sequential Read and Write, NPAD=1

We can glimpse a few more details of the prefetch implementation by looking at the data of test runs where the list elements are modified. Figure 3.13 shows three lines. The element width is in all cases 16 bytes. The first line is the now familiar list walk which serves as a baseline. The second line, labeled “Inc”, simply increments the pad[0] member of the current element before going on to the next. The third line, labeled “Addnext0”, takes the pad[0] list element of the next element and adds it to the pad[0] member of the current list element.

The naïve assumption would be that the “Addnext0” test runs slower because it has more work to do. Before advancing to the next list element a value from that element has to be loaded. This is why it is surprising to see that this test actually runs, for some working set sizes, faster than the “Inc” test. The explanation for this is that the load from the next list element is basically a forced prefetch. Whenever the program advances to the next list element we know for sure that element is already in the L1d cache. As a result we see that the “Addnext0” performs as well as the simple “Follow” test as long as the working set size fits into the L2 cache.

The “Addnext0” test runs out of L2 faster than the “Inc” test, though. It needs more data loaded from main memory. This is why the “Addnext0” test reaches the 28 cycles level for a working set size of 2²¹ bytes. The 28 cycles level is twice as high as the 14 cycles level the “Follow” test reaches. This is easy to explain, too. Since the other two tests modify memory an L2 cache eviction to make room for new cache lines cannot simply discard the data. Instead it has to be written to memory. This means the available bandwidth on the FSB is cut in half, hence doubling the time it takes to transfer the data from main memory to L2.

Figure 3.14: Advantage of Larger L2/L3 Caches

One last aspect of the sequential, efficient cache handling is the size of the cache. This should be obvious but it still should be pointed out. Figure 3.14 shows the timing for the Increment benchmark with 128-byte elements (NPAD=15 on 64-bit machines). This time we see the measurement from three different machines. The first two machines are P4s, the last one a Core2 processor. The first two differentiate themselves by having different cache sizes. The first processor has a 32k L1d and an 1M L2. The second one has 16k L1d, 512k L2, and 2M L3. The Core2 processor has 32k L1d and 4M L2.

The interesting part of the graph is not necessarily how well the Core2 processor performs relative to the other two (although it is impressive). The main point of interest here is the region where the working set size is too large for the respective last level cache and the main memory gets heavily involved.

Set Size	Sequential					Random
	L2 Hit	L2 Miss	#Iter	Ratio Miss/Hit	L2 Accesses Per Iter	L2 Hit	L2 Miss	#Iter	Ratio Miss/Hit	L2 Accesses Per Iter
220	88,636	843	16,384	0.94%	5.5	30,462	4721	1,024	13.42%	34.4
221	88,105	1,584	8,192	1.77%	10.9	21,817	15,151	512	40.98%	72.2
222	88,106	1,600	4,096	1.78%	21.9	22,258	22,285	256	50.03%	174.0
223	88,104	1,614	2,048	1.80%	43.8	27,521	26,274	128	48.84%	420.3
224	88,114	1,655	1,024	1.84%	87.7	33,166	29,115	64	46.75%	973.1
225	88,112	1,730	512	1.93%	175.5	39,858	32,360	32	44.81%	2,256.8
226	88,112	1,906	256	2.12%	351.6	48,539	38,151	16	44.01%	5,418.1
227	88,114	2,244	128	2.48%	705.9	62,423	52,049	8	45.47%	14,309.0
228	88,120	2,939	64	3.23%	1,422.8	81,906	87,167	4	51.56%	42,268.3
229	88,137	4,318	32	4.67%	2,889.2	119,079	163,398	2	57.84%	141,238.5

Table 3.2: L2 Hits and Misses for Sequential and Random Walks, NPAD=0

As expected, the larger the last level cache is the longer the curve stays at the low level corresponding to the L2 access costs. The important part to notice is the performance advantage this provides. The second processor (which is slightly older) can perform the work on the working set of 2²⁰ bytes twice as fast as the first processor. All thanks to the increased last level cache size. The Core2 processor with its 4M L2 performs even better.

For a random workload this might not mean that much. But if the workload can be tailored to the size of the last level cache the program performance can be increased quite dramatically. This is why it sometimes is worthwhile to spend the extra money for a processor with a larger cache.

Single Threaded Random Access Measurements

We have seen that the processor is able to hide most of the main memory and even L2 access latency by prefetching cache lines into L2 and L1d. This can work well only when the memory access is predictable, though.

Figure 3.15: Sequential vs Random Read, NPAD=0

If the access is unpredictable or random the situation is quite different. Figure 3.15 compares the per-list-element times for the sequential access (same as in Figure 3.10) with the times when the list elements are randomly distributed in the working set. The order is determined by the linked list which is randomized. There is no way for the processor to reliably prefetch data. This can only work by chance if elements which are used shortly after one another are also close to each other in memory.

There are two important points to note in Figure 3.15. First, the large number is cycles needed for growing working set sizes. The machine makes it possible to access the main memory in 200-300 cycles but here we reach 450 cycles and more. We have seen this phenomenon before (compare Figure 3.11). The automatic prefetching is actually working to a disadvantage here.

The second interesting point is that the curve is not flattening at various plateaus as it has been for the sequential access cases. The curve keeps on rising. To explain this we can measure the L2 access of the program for the various working set sizes. The result can be seen in Figure 3.16 and Table 3.2.

The figure shows that, when the working set size is larger than the L2 size, the cache miss ratio (L2 misses / L2 access) starts to grow. The curve has a similar form to the one in Figure 3.15: it rises quickly, declines slightly, and starts to rise again. There is a strong correlation with the cycles per list element graph. The L2 miss rate will grow until it eventually reaches close to 100%. Given a large enough working set (and RAM) the probability that any of the randomly picked cache lines is in L2 or is in the process of being loaded can be reduced arbitrarily.

The increasing cache miss rate alone explains some of the costs. But there is another factor. Looking at Table 3.2 we can see in the L2/#Iter columns that the total number of L2 uses per iteration of the program is growing. Each working set is twice as large as the one before. So, without caching we would expect double the main memory accesses. With caches and (almost) perfect predictability we see the modest increase in the L2 use shown in the data for sequential access. The increase is due to the increase of the working set size and nothing else.

Figure 3.16: L2d Miss Ratio

Figure 3.17: Page-Wise Randomization, NPAD=7

For random access the per-element time increases by more than 100% for each doubling of the working set size. This means the average access time per list element increases since the working set size only doubles. The reason behind this is a rising rate of TLB misses. In Figure 3.17 we see the cost for random accesses for NPAD=7. Only this time the randomization is modified. While in the normal case the entire list of randomized as one block (indicated by the label ∞) the other 11 curves show randomizations which are performed in smaller blocks. For the curve labeled '60' each set of 60 pages (245.760 bytes) is randomized individually. That means all list elements in the block are traversed before going over to an element in the next block. This has the effect that number of TLB entries which are used at any one time is limited.

The element size for NPAD=7 is 64 bytes, which corresponds to the cache line size. Due to the randomized order of the list elements it is unlikely that the hardware prefetcher has any effect, most certainly not for more than a handful of elements. This means the L2 cache miss rate does not differ significantly from the randomization of the entire list in one block. The performance of the test with increasing block size approaches asymptotically the curve for the one-block randomization. This means the performance of this latter test case is significantly influenced by the TLB misses. If the TLB misses can be lowered the performance increases significantly (in one test we will see later up to 38%).

3.3.3 Write Behavior

Before we start looking at the cache behavior when multiple execution contexts (threads or processes) use the same memory we have to explore a detail of cache implementations. Caches are supposed to be coherent and this coherency is supposed to be completely transparent for the userlevel code. Kernel code is a different story; it occasionally requires cache flushes.

This specifically means that, if a cache line is modified, the result for the system after this point in time is the same as if there were no cache at all and the main memory location itself had been modified. This can be implemented in two ways or policies:

• write-through cache implementation;
• write-back cache implementation.

The write-through cache is the simplest way to implement cache coherency. If the cache line is written to, the processor immediately also writes the cache line into main memory. This ensures that, at all times, the main memory and cache are in sync. The cache content could simply be discarded whenever a cache line is replaced. This cache policy is simple but not very fast. A program which, for instance, modifies a local variable over and over again would create a lot of traffic on the FSB even though the data is likely not used anywhere else and might be short-lived.

The write-back policy is more sophisticated. Here the processor does not immediately write the modified cache line back to main memory. Instead, the cache line is only marked as dirty. When the cache line is dropped from the cache at some point in the future the dirty bit will instruct the processor to write the data back at that time instead of just discarding the content.

Write-back caches have the chance to be significantly better performing, which is why most memory in a system with a decent processor is cached this way. The processor can even take advantage of free capacity on the FSB to store the content of a cache line before the line has to be evacuated. This allows the dirty bit to be cleared and the processor can just drop the cache line when the room in the cache is needed.

But there is a significant problem with the write-back implementation. When more than one processor (or core or hyper-thread) is available and accessing the same memory it must still be assured that both processors see the same memory content at all times. If a cache line is dirty on one processor (i.e., it has not been written back yet) and a second processor tries to read the same memory location, the read operation cannot just go out to the main memory. Instead the content of the first processor's cache line is needed. In the next section we will see how this is currently implemented.

Before we get to this there are two more cache policies to mention:

• write-combining; and
• uncacheable.

Both these policies are used for special regions of the address space which are not backed by real RAM. The kernel sets up these policies for the address ranges (on x86 processors using the Memory Type Range Registers, MTRRs) and the rest happens automatically. The MTRRs are also usable to select between write-through and write-back policies.

Write-combining is a limited caching optimization more often used for RAM on devices such as graphics cards. Since the transfer costs to the devices are much higher than the local RAM access it is even more important to avoid doing too many transfers. Transferring an entire cache line just because a word in the line has been written is wasteful if the next operation modifies the next word. One can easily imagine that this is a common occurrence, the memory for horizontal neighboring pixels on a screen are in most cases neighbors, too. As the name suggests, write-combining combines multiple write accesses before the cache line is written out. In ideal cases the entire cache line is modified word by word and, only after the last word is written, the cache line is written to the device. This can speed up access to RAM on devices significantly.

Finally there is uncacheable memory. This usually means the memory location is not backed by RAM at all. It might be a special address which is hardcoded to have some functionality outside the CPU. For commodity hardware this most often is the case for memory mapped address ranges which translate to accesses to cards and devices attached to a bus (PCIe etc). On embedded boards one sometimes finds such a memory address which can be used to turn an LED on and off. Caching such an address would obviously be a bad idea. LEDs in this context are used for debugging or status reports and one wants to see this as soon as possible. The memory on PCIe cards can change without the CPU's interaction, so this memory should not be cached.

3.3.4 Multi-Processor Support

In the previous section we have already pointed out the problem we have when multiple processors come into play. Even multi-core processors have the problem for those cache levels which are not shared (at least the L1d).

It is completely impractical to provide direct access from one processor to the cache of another processor. The connection is simply not fast enough, for a start. The practical alternative is to transfer the cache content over to the other processor in case it is needed. Note that this also applies to caches which are not shared on the same processor.

The question now is when does this cache line transfer have to happen? This question is pretty easy to answer: when one processor needs a cache line which is dirty in another processor's cache for reading or writing. But how can a processor determine whether a cache line is dirty in another processor's cache? Assuming it is just because a cache line is loaded by another processor would be suboptimal (at best). Usually the majority of memory accesses are read accesses and the resulting cache lines are not dirty. Processor operations on cache lines are frequent (of course, why else would we have this paper?) which means broadcasting information about changed cache lines after each write access would be impractical.

What developed over the years is the MESI cache coherency protocol (Modified, Exclusive, Shared, Invalid). The protocol is named after the four states a cache line can be in when using the MESI protocol:

• Modified: The local processor has modified the cache line. This also implies it is the only copy in any cache.

• Exclusive: The cache line is not modified but known to not be loaded into any other processor's cache.

• Shared: The cache line is not modified and might exist in another processor's cache.

• Invalid: The cache line is invalid, i.e., unused.

This protocol developed over the years from simpler versions which were less complicated but also less efficient. With these four states it is possible to efficiently implement write-back caches while also supporting concurrent use of read-only data on different processors.

Figure 3.18: MESI Protocol Transitions

The state changes are accomplished without too much effort by the processors listening, or snooping, on the other processors' work. Certain operations a processor performs are announced on external pins and thus make the processor's cache handling visible to the outside. The address of the cache line in question is visible on the address bus. In the following description of the states and their transitions (shown in Figure 3.18) we will point out when the bus is involved.

Initially all cache lines are empty and hence also Invalid. If data is loaded into the cache for writing the cache changes to Modified. If the data is loaded for reading the new state depends on whether another processor has the cache line loaded as well. If this is the case then the new state is Shared, otherwise Exclusive.

If a Modified cache line is read from or written to on the local processor, the instruction can use the current cache content and the state does not change. If a second processor wants to read from the cache line the first processor has to send the content of its cache to the second processor and then it can change the state to Shared. The data sent to the second processor is also received and processed by the memory controller which stores the content in memory. If this did not happen the cache line could not be marked as Shared. If the second processor wants to write to the cache line the first processor sends the cache line content and marks the cache line locally as Invalid. This is the infamous “Request For Ownership” (RFO) operation. Performing this operation in the last level cache, just like the I→M transition is comparatively expensive. For write-through caches we also have to add the time it takes to write the new cache line content to the next higher-level cache or the main memory, further increasing the cost.

If a cache line is in the Shared state and the local processor reads from it no state change is necessary and the read request can be fulfilled from the cache. If the cache line is locally written to the cache line can be used as well but the state changes to Modified. It also requires that all other possible copies of the cache line in other processors are marked as Invalid. Therefore the write operation has to be announced to the other processors via an RFO message. If the cache line is requested for reading by a second processor nothing has to happen. The main memory contains the current data and the local state is already Shared. In case a second processor wants to write to the cache line (RFO) the cache line is simply marked Invalid. No bus operation is needed.

The Exclusive state is mostly identical to the Shared state with one crucial difference: a local write operation does not have to be announced on the bus. The local cache copy is known to be the only one. This can be a huge advantage so the processor will try to keep as many cache lines as possible in the Exclusive state instead of the Shared state. The latter is the fallback in case the information is not available at that moment. The Exclusive state can also be left out completely without causing functional problems. It is only the performance that will suffer since the E→M transition is much faster than the S→M transition.

From this description of the state transitions it should be clear where the costs specific to multi-processor operations are. Yes, filling caches is still expensive but now we also have to look out for RFO messages. Whenever such a message has to be sent things are going to be slow.

There are two situations when RFO messages are necessary:

• A thread is migrated from one processor to another and all the cache lines have to be moved over to the new processor once.

• A cache line is truly needed in two different processors. {At a smaller level the same is true for two cores on the same processor. The costs are just a bit smaller. The RFO message is likely to be sent many times.}

In multi-thread or multi-process programs there is always some need for synchronization; this synchronization is implemented using memory. So there are some valid RFO messages. They still have to be kept as infrequent as possible. There are other sources of RFO messages, though. In Section 6 we will explain these scenarios. The Cache coherency protocol messages must be distributed among the processors of the system. A MESI transition cannot happen until it is clear that all the processors in the system have had a chance to reply to the message. That means that the longest possible time a reply can take determines the speed of the coherency protocol. {Which is why we see nowadays, for instance, AMD Opteron systems with three sockets. Each processor is exactly one hop away given that the processors only have three hyperlinks and one is needed for the Southbridge connection.} Collisions on the bus are possible, latency can be high in NUMA systems, and of course sheer traffic volume can slow things down. All good reasons to focus on avoiding unnecessary traffic.

There is one more problem related to having more than one processor in play. The effects are highly machine specific but in principle the problem always exists: the FSB is a shared resource. In most machines all processors are connected via one single bus to the memory controller (see Figure 2.1). If a single processor can saturate the bus (as is usually the case) then two or four processors sharing the same bus will restrict the bandwidth available to each processor even more.

Even if each processor has its own bus to the memory controller as in Figure 2.2 there is still the bus to the memory modules. Usually this is one bus but, even in the extended model in Figure 2.2, concurrent accesses to the same memory module will limit the bandwidth.

The same is true with the AMD model where each processor can have local memory. Yes, all processors can concurrently access their local memory quickly. But multi-thread and multi-process programs--at least from time to time--have to access the same memory regions to synchronize.

Concurrency is severely limited by the finite bandwidth available for the implementation of the necessary synchronization. Programs need to be carefully designed to minimize accesses from different processors and cores to the same memory locations. The following measurements will show this and the other cache effects related to multi-threaded code.

Multi Threaded Measurements

To ensure that the gravity of the problems introduced by concurrently using the same cache lines on different processors is understood, we will look here at some more performance graphs for the same program we used before. This time, though, more than one thread is running at the same time. What is measured is the fastest runtime of any of the threads. This means the time for a complete run when all threads are done is even higher. The machine used has four processors; the tests use up to four threads. All processors share one bus to the memory controller and there is only one bus to the memory modules.

Figure 3.19: Sequential Read Access, Multiple Threads

Figure 3.19 shows the performance for sequential read-only access for 128 bytes entries (NPAD=15 on 64-bit machines). For the curve for one thread we can expect a curve similar to Figure 3.11. The measurements are for a different machine so the actual numbers vary.

The important part in this figure is of course the behavior when running multiple threads. Note that no memory is modified and no attempts are made to keep the threads in sync when walking the linked list. Even though no RFO messages are necessary and all the cache lines can be shared, we see up to an 18% performance decrease for the fastest thread when two threads are used and up to 34% when four threads are used. Since no cache lines have to be transported between the processors this slowdown is solely caused by one or both of the two bottlenecks: the shared bus from the processor to the memory controller and bus from the memory controller to the memory modules. Once the working set size is larger than the L3 cache in this machine all three threads will be prefetching new list elements. Even with two threads the available bandwidth is not sufficient to scale linearly (i.e., have no penalty from running multiple threads).

When we modify memory things get even uglier. Figure 3.20 shows the results for the sequential Increment test.

Figure 3.20: Sequential Increment, Multiple Threads

This graph is using a logarithmic scale for the Y axis. So, do not be fooled by the apparently small differences. We still have about a 18% penalty for running two threads and now an amazing 93% penalty for running four threads. This means the prefetch traffic together with the write-back traffic is pretty much saturating the bus when four threads are used.

We use the logarithmic scale to show the results for the L1d range. What can be seen is that, as soon as more than one thread is running, the L1d is basically ineffective. The single-thread access times exceed 20 cycles only when the L1d is not sufficient to hold the working set. When multiple threads are running, those access times are hit immediately, even with the smallest working set sizes.

One aspect of the problem is not shown here. It is hard to measure with this specific test program. Even though the test modifies memory and we therefore must expect RFO messages we do not see higher costs for the L2 range when more than one thread is used. The program would have to use a large amount of memory and all threads must access the same memory in parallel. This is hard to achieve without a lot of synchronization which would then dominate the execution time.

Figure 3.21: Random Addnextlast, Multiple Threads

Finally in Figure 3.21 we have the numbers for the Addnextlast test with random access of memory. This figure is provided mainly to show to the appallingly high numbers. It now take around 1,500 cycles to process a single list element in the extreme case. The use of more threads is even more questionable. We can summarize the efficiency of multiple thread use in a table.

#Threads	Seq Read	Seq Inc	Rand Add
2	1.69	1.69	1.54
4	2.98	2.07	1.65

Table 3.3: Efficiency for Multiple Threads

The table shows the efficiency for the multi-thread run with the largest working set size in the three figures on Figure 3.21. The number shows the best possible speed-up the test program incurs for the largest working set size by using two or four threads. For two threads the theoretical limits for the speed-up are 2 and, for four threads, 4. The numbers for two threads are not that bad. But for four threads the numbers for the last test show that it is almost not worth it to scale beyond two threads. The additional benefit is minuscule. We can see this more easily if we represent the data in Figure 3.21 a bit differently.

Figure 3.22: Speed-Up Through Parallelism

The curves in Figure 3.22 show the speed-up factors, i.e., relative performance compared to the code executed by a single thread. We have to ignore the smallest sizes, the measurements are not accurate enough. For the range of the L2 and L3 cache we can see that we indeed achieve almost linear acceleration. We almost reach factors of 2 and 4 respectively. But as soon as the L3 cache is not sufficient to hold the working set the numbers crash. They crash to the point that the speed-up of two and four threads is identical (see the fourth column in Table 3.3). This is one of the reasons why one can hardly find motherboard with sockets for more than four CPUs all using the same memory controller. Machines with more processors have to be built differently (see Section 5).

These numbers are not universal. In some cases even working sets which fit into the last level cache will not allow linear speed-ups. In fact, this is the norm since threads are usually not as decoupled as is the case in this test program. On the other hand it is possible to work with large working sets and still take advantage of more than two threads. Doing this requires thought, though. We will talk about some approaches in Section 6.

Special Case: Hyper-Threads

Hyper-Threads (sometimes called Symmetric Multi-Threading, SMT) are implemented by the CPU and are a special case since the individual threads cannot really run concurrently. They all share almost all the processing resources except for the register set. Individual cores and CPUs still work in parallel but the threads implemented on each core are limited by this restriction. In theory there can be many threads per core but, so far, Intel's CPUs at most have two threads per core. The CPU is responsible for time-multiplexing the threads. This alone would not make much sense, though. The real advantage is that the CPU can schedule another hyper-thread when the currently running hyper-thread is delayed. In most cases this is a delay caused by memory accesses.

If two threads are running on one hyper-threaded core the program is only more efficient than the single-threaded code if the combined runtime of both threads is lower than the runtime of the single-threaded code. This is possible by overlapping the wait times for different memory accesses which usually would happen sequentially. A simple calculation shows the minimum requirement on the cache hit rate to achieve a certain speed-up.

The execution time for a program can be approximated with a simple model with only one level of cache as follows (see [htimpact]):

T_exe = N[(1-F_mem)T_proc + F_mem(G_hitT_cache + (1-G_hit)T_miss)]

The meaning of the variables is as follows:

N	=	Number of instructions.
Fmem	=	Fraction of N that access memory.
Ghit	=	Fraction of loads that hit the cache.
Tproc	=	Number of cycles per instruction.
Tcache	=	Number of cycles for cache hit.
Tmiss	=	Number of cycles for cache miss.
Texe	=	Execution time for program.

For it to make any sense to use two threads the execution time of each of the two threads must be at most half of that of the single-threaded code. The only variable on either side is the number of cache hits. If we solve the equation for the minimum cache hit rate required to not slow down the thread execution by 50% or more we get the graph in Figure 3.23.

Figure 3.23: Minimum Cache Hit Rate For Speed-Up

The X–axis represents the cache hit rate G_hit of the single-thread code. The Y–axis shows the required cache hit rate for the multi-threaded code. This value can never be higher than the single-threaded hit rate since, otherwise, the single-threaded code would use that improved code, too. For single-threaded hit rates below 55% the program can in all cases benefit from using threads. The CPU is more or less idle enough due to cache misses to enable running a second hyper-thread.

The green area is the target. If the slowdown for the thread is less than 50% and the workload of each thread is halved the combined runtime might be less than the single-thread runtime. For the modeled system here (numbers for a P4 with hyper-threads were used) a program with a hit rate of 60% for the single-threaded code requires a hit rate of at least 10% for the dual-threaded program. That is usually doable. But if the single-threaded code has a hit rate of 95% then the multi-threaded code needs a hit rate of at least 80%. That is harder. Especially, and this is the problem with hyper-threads, because now the effective cache size (L1d here, in practice also L2 and so on) available to each hyper-thread is cut in half. Both hyper-threads use the same cache to load their data. If the working set of the two threads is non-overlapping the original 95% hit rate could also be cut in half and is therefore much lower than the required 80%.

Hyper-Threads are therefore only useful in a limited range of situations. The cache hit rate of the single-threaded code must be low enough that given the equations above and reduced cache size the new hit rate still meets the goal. Then and only then can it make any sense at all to use hyper-threads. Whether the result is faster in practice depends on whether the processor is sufficiently able to overlap the wait times in one thread with execution times in the other threads. The overhead of parallelizing the code must be added to the new total runtime and this additional cost often cannot be neglected.

In Section 6.3.4 we will see a technique where threads collaborate closely and the tight coupling through the common cache is actually an advantage. This technique can be applicable to many situations if only the programmers are willing to put in the time and energy to extend their code.

What should be clear is that if the two hyper-threads execute completely different code (i.e., the two threads are treated like separate processors by the OS to execute separate processes) the cache size is indeed cut in half which means a significant increase in cache misses. Such OS scheduling practices are questionable unless the caches are sufficiently large. Unless the workload for the machine consists of processes which, through their design, can indeed benefit from hyper-threads it might be best to turn off hyper-threads in the computer's BIOS. {Another reason to keep hyper-threads enabled is debugging. SMT is astonishingly good at finding some sets of problems in parallel code.}

3.3.5 Other Details

So far we talked about the address as consisting of three parts, tag, set index, and cache line offset. But what address is actually used? All relevant processors today provide virtual address spaces to processes, which means that there are two different kinds of addresses: virtual and physical.

The problem with virtual addresses is that they are not unique. A virtual address can, over time, refer to different physical memory addresses. The same address in different process also likely refers to different physical addresses. So it is always better to use the physical memory address, right?

The problem here is that instructions use virtual addresses and these have to be translated with the help of the Memory Management Unit (MMU) into physical addresses. This is a non-trivial operation. In the pipeline to execute an instruction the physical address might only be available at a later stage. This means that the cache logic has to be very quick in determining whether the memory location is cached. If virtual addresses could be used the cache lookup can happen much earlier in the pipeline and in case of a cache hit the memory content can be made available. The result is that more of the memory access costs could be hidden by the pipeline.

Processor designers are currently using virtual address tagging for the first level caches. These caches are rather small and can be cleared without too much pain. At least partial clearing the cache is necessary if the page table tree of a process changes. It might be possible to avoid a complete flush if the processor has an instruction which specifies the virtual address range which has changed. Given the low latency of L1i and L1d caches (~3 cycles) using virtual addresses is almost mandatory.

For larger caches including L2, L3, ... caches physical address tagging is needed. These caches have a higher latency and the virtual→physical address translation can finish in time. Because these caches are larger (i.e., a lot of information is lost when they are flushed) and refilling them takes a long time due to the main memory access latency, flushing them often would be costly.

It should, in general, not be necessary to know about the details of the address handling in those caches. They cannot be changed and all the factors which would influence the performance are normally something which should be avoided or is associated with high cost. Overflowing the cache capacity is bad and all caches run into problems early if the majority of the used cache lines fall into the same set. The latter can be avoided with virtually addressed caches but is impossible for user-level processes to avoid for caches addressed using physical addresses. The only detail one might want to keep in mind is to not map the same physical memory location to two or more virtual addresses in the same process, if at all possible.

Another detail of the caches which is rather uninteresting to programmers is the cache replacement strategy. Most caches evict the Least Recently Used (LRU) element first. This is always a good default strategy. With larger associativity (and associativity might indeed grow further in the coming years due to the addition of more cores) maintaining the LRU list becomes more and more expensive and we might see different strategies adopted.

As for the cache replacement there is not much a programmer can do. If the cache is using physical address tags there is no way to find out how the virtual addresses correlate with the cache sets. It might be that cache lines in all logical pages are mapped to the same cache sets, leaving much of the cache unused. If anything, it is the job of the OS to arrange that this does not happen too often.

With the advent of virtualization things get even more complicated. Now not even the OS has control over the assignment of physical memory. The Virtual Machine Monitor (VMM, aka hypervisor) is responsible for the physical memory assignment.

The best a programmer can do is to a) use logical memory pages completely and b) use page sizes as large as meaningful to diversify the physical addresses as much as possible. Larger page sizes have other benefits, too, but this is another topic (see Section 4).

3.4 Instruction Cache

Not just the data used by the processor is cached; the instructions executed by the processor are also cached. However, this cache is much less problematic than the data cache. There are several reasons:

• The quantity of code which is executed depends on the size of the code that is needed. The size of the code in general depends on the complexity of the problem. The complexity of the problem is fixed.

• While the program's data handling is designed by the programmer the program's instructions are usually generated by a compiler. The compiler writers know about the rules for good code generation.

• Program flow is much more predictable than data access patterns. Today's CPUs are very good at detecting patterns. This helps with prefetching.

• Code always has quite good spatial and temporal locality.

There are a few rules programmers should follow but these mainly consist of rules on how to use the tools. We will discuss them in Section 6. Here we talk only about the technical details of the instruction cache.

Ever since the core clock of CPUs increased dramatically and the difference in speed between cache (even first level cache) and core grew, CPUs have been pipelined. That means the execution of an instruction happens in stages. First an instruction is decoded, then the parameters are prepared, and finally it is executed. Such a pipeline can be quite long (> 20 stages for Intel's Netburst architecture). A long pipeline means that if the pipeline stalls (i.e., the instruction flow through it is interrupted) it takes a while to get up to speed again. Pipeline stalls happen, for instance, if the location of the next instruction cannot be correctly predicted or if it takes too long to load the next instruction (e.g., when it has to be read from memory).

As a result CPU designers spend a lot of time and chip real estate on branch prediction so that pipeline stalls happen as infrequently as possible.

On CISC processors the decoding stage can also take some time. The x86 and x86-64 processors are especially affected. In recent years these processors therefore do not cache the raw byte sequence of the instructions in L1i but instead they cache the decoded instructions. L1i in this case is called the “trace cache”. Trace caching allows the processor to skip over the first steps of the pipeline in case of a cache hit which is especially good if the pipeline stalled.

As said before, the caches from L2 on are unified caches which contain both code and data. Obviously here the code is cached in the byte sequence form and not decoded.

To achieve the best performance there are only a few rules related to the instruction cache:

1. Generate code which is as small as possible. There are exceptions when software pipelining for the sake of using pipelines requires creating more code or where the overhead of using small code is too high.

2. Whenever possible, help the processor to make good prefetching decisions. This can be done through code layout or with explicit prefetching.

These rules are usually enforced by the code generation of a compiler. There are a few things the programmer can do and we will talk about them in Section 6.

3.4.1 Self Modifying Code

In early computer days memory was a premium. People went to great lengths to reduce the size of the program to make more room for program data. One trick frequently deployed was to change the program itself over time. Such Self Modifying Code (SMC) is occasionally still found, these days mostly for performance reasons or in security exploits.

SMC should in general be avoided. Though it is generally executed correctly there are boundary cases in which it is not and it creates performance problems if not done correctly. Obviously, code which is changed cannot be kept in the trace cache which contains the decoded instructions. But even if the trace cache is not used because the code has not been executed at all (or for some time) the processor might have problems. If an upcoming instruction is changed while it already entered the pipeline the processor has to throw away a lot of work and start all over again. There are even situations where most of the state of the processor has to be tossed away.

Finally, since the processor assumes - for simplicity reasons and because it is true in 99.9999999% of all cases - that the code pages are immutable, the L1i implementation does not use the MESI protocol but instead a simplified SI protocol. This means if modifications are detected a lot of pessimistic assumptions have to be made.

It is highly advised to avoid SMC whenever possible. Memory is not such a scarce resource anymore. It is better to write separate functions instead of modifying one function according to specific needs. Maybe one day SMC support can be made optional and we can detect exploit code trying to modify code this way. If SMC absolutely has to be used, the write operations should bypass the cache as to not create problems with data in L1d needed in L1i. See Section 6.1 for more information on these instructions.

Normally on Linux it is easy to recognize programs which contain SMC. All program code is write-protected when built with the regular toolchain. The programmer has to perform significant magic at link time to create an executable where the code pages are writable. When this happens, modern Intel x86 and x86-64 processors have dedicated performance counters which count uses of self-modifying code. With the help of these counters it is quite easily possible to recognize programs with SMC even if the program will succeed due to relaxed permissions.

3.5 Cache Miss Factors

We have already seen that when memory accesses miss the caches, the costs skyrocket. Sometimes this is not avoidable and it is important to understand the actual costs and what can be done to mitigate the problem.

3.5.1 Cache and Memory Bandwidth

To get a better understanding of the capabilities of the processors we measure the bandwidth available in optimal circumstances. This measurement is especially interesting since different processor versions vary widely. This is why this section is filled with the data of several different machines. The program to measure performance uses the SSE instructions of the x86 and x86-64 processors to load or store 16 bytes at once. The working set is increased from 1kB to 512MB just as in our other tests and it is measured how many bytes per cycle can be loaded or stored.

Figure 3.24: Pentium 4 Bandwidth

Figure 3.24 shows the performance on a 64-bit Intel Netburst processor. For working set sizes which fit into L1d the processor is able to read the full 16 bytes per cycle, i.e., one load instruction is performed per cycle (the movaps instruction moves 16 bytes at once). The test does not do anything with the read data, we test only the read instructions themselves. As soon as the L1d is not sufficient anymore the performance goes down dramatically to less than 6 bytes per cycle. The step at 2¹⁸ bytes is due to the exhaustion of the DTLB cache which means additional work for each new page. Since the reading is sequential prefetching can predict the accesses perfectly and the FSB can stream the memory content at about 5.3 bytes per cycle for all sizes of the working set. The prefetched data is not propagated into L1d, though. These are of course numbers which will never be achievable in a real program. Think of them as practical limits.

What is more astonishing than the read performance is the write and copy performance. The write performance, even for small working set sizes, does not ever rise above 4 bytes per cycle. This indicates that, in these Netburst processors, Intel elected to use a Write-Through mode for L1d where the performance is obviously limited by the L2 speed. This also means that the performance of the copy test, which copies from one memory region into a second, non-overlapping memory region, is not significantly worse. The necessary read operations are so much faster and can partially overlap with the write operations. The most noteworthy detail of the write and copy measurements is the low performance once the L2 cache is not sufficient anymore. The performance drops to 0.5 bytes per cycle! That means write operations are by a factor of ten slower than the read operations. This means optimizing those operations is even more important for the performance of the program.

In Figure 3.25 we see the results on the same processor but with two threads running, one pinned to each of the two hyper-threads of the processor.

Figure 3.25: P4 Bandwidth with 2 Hyper-Threads

The graph is shown at the same scale as the previous one to illustrate the differences and the curves are a bit jittery simply because of the problem of measuring two concurrent threads. The results are as expected. Since the hyper-threads share all the resources except the registers each thread has only half the cache and bandwidth available. That means even though each thread has to wait a lot and could award the other thread with execution time this does not make any difference since the other thread also has to wait for the memory. This truly shows the worst possible use of hyper-threads.

Figure 3.26: Core 2 Bandwidth

Compared to Figures 3.24 and 3.25 the results in Figures 3.26 and 3.27 look quite different for an Intel Core 2 processor. This is a dual-core processor with shared L2 which is four times as big as the L2 on the P4 machine. This only explains the delayed drop-off of the write and copy performance, though.

There are much bigger differences. The read performance throughout the working set range hovers around the optimal 16 bytes per cycle. The drop-off in the read performance after 2²⁰ bytes is again due to the working set being too big for the DTLB. Achieving these high numbers means the processor is not only able to prefetch the data and transport the data in time. It also means the data is prefetched into L1d.

The write and copy performance is dramatically different, too. The processor does not have a Write-Through policy; written data is stored in L1d and only evicted when necessary. This allows for write speeds close to the optimal 16 bytes per cycle. Once L1d is not sufficient anymore the performance drops significantly. As with the Netburst processor, the write performance is significantly lower. Due to the high read performance the difference is even higher here. In fact, when even the L2 is not sufficient anymore the speed difference increases to a factor of 20! This does not mean the Core 2 processors perform poorly. To the contrary, their performance is always better than the Netburst core's.

Figure 3.27: Core 2 Bandwidth with 2 Threads

In Figure 3.27, the test runs two threads, one on each of the two cores of the Core 2 processor. Both threads access the same memory, not necessarily perfectly in sync, though. The results for the read performance are not different from the single-threaded case. A few more jitters are visible which is to be expected in any multi-threaded test case.

The interesting point is the write and copy performance for working set sizes which would fit into L1d. As can be seen in the figure, the performance is the same as if the data had to be read from the main memory. Both threads compete for the same memory location and RFO messages for the cache lines have to be sent. The problematic point is that these requests are not handled at the speed of the L2 cache, even though both cores share the cache. Once the L1d cache is not sufficient anymore modified entries are flushed from each core's L1d into the shared L2. At that point the performance increases significantly since now the L1d misses are satisfied by the L2 cache and RFO messages are only needed when the data has not yet been flushed. This is why we see a 50% reduction in speed for these sizes of the working set. The asymptotic behavior is as expected: since both cores share the same FSB each core gets half the FSB bandwidth which means for large working sets each thread's performance is about half that of the single threaded case.

Because there are significant differences between the processor versions of one vendor it is certainly worthwhile looking at the performance of other vendors' processors, too. Figure 3.28 shows the performance of an AMD family 10h Opteron processor. This processor has 64kB L1d, 512kB L2, and 2MB of L3. The L3 cache is shared between all cores of the processor. The results of the performance test can be seen in Figure 3.28.

Figure 3.28: AMD Family 10h Opteron Bandwidth

The first detail one notices about the numbers is that the processor is capable of handling two instructions per cycle if the L1d cache is sufficient. The read performance exceeds 32 bytes per cycle and even the write performance is, with 18.7 bytes per cycle, high. The read curve flattens quickly, though, and is, with 2.3 bytes per cycle, pretty low. The processor for this test does not prefetch any data, at least not efficiently.

The write curve on the other hand performs according to the sizes of the various caches. The peak performance is achieved for the full size of the L1d, going down to 6 bytes per cycle for L2, to 2.8 bytes per cycle for L3, and finally .5 bytes per cycle if not even L3 can hold all the data. The performance for the L1d cache exceeds that of the (older) Core 2 processor, the L2 access is equally fast (with the Core 2 having a larger cache), and the L3 and main memory access is slower.

The copy performance cannot be better than either the read or write performance. This is why we see the curve initially dominated by the read performance and later by the write performance.

The multi-thread performance of the Opteron processor is shown in Figure 3.29.

Figure 3.29: AMD Fam 10h Bandwidth with 2 Threads

The read performance is largely unaffected. Each thread's L1d and L2 works as before and the L3 cache is in this case not prefetched very well either. The two threads do not unduly stress the L3 for their purpose. The big problem in this test is the write performance. All data the threads share has to go through the L3 cache. This sharing seems to be quite inefficient since even if the L3 cache size is sufficient to hold the entire working set the cost is significantly higher than an L3 access. Comparing this graph with Figure 3.27 we see that the two threads of the Core 2 processor operate at the speed of the shared L2 cache for the appropriate range of working set sizes. This level of performance is achieved for the Opteron processor only for a very small range of the working set sizes and even here it approaches only the speed of the L3 which is slower than the Core 2's L2.

3.5.2 Critical Word Load

Memory is transferred from the main memory into the caches in blocks which are smaller than the cache line size. Today 64 bits are transferred at once and the cache line size is 64 or 128 bytes. This means 8 or 16 transfers per cache line are needed.

The DRAM chips can transfer those 64-bit blocks in burst mode. This can fill the cache line without any further commands from the memory controller and the possibly associated delays. If the processor prefetches cache lines this is probably the best way to operate.

If a program's cache access of the data or instruction caches misses (that means, it is a compulsory cache miss, because the data is used for the first time, or a capacity cache miss, because the limited cache size requires eviction of the cache line) the situation is different. The word inside the cache line which is required for the program to continue might not be the first word in the cache line. Even in burst mode and with double data rate transfer the individual 64-bit blocks arrive at noticeably different times. Each block arrives 4 CPU cycles or more later than the previous one. If the word the program needs to continue is the eighth of the cache line, the program has to wait an additional 30 cycles or more after the first word arrives.

Things do not necessarily have to be like this. The memory controller is free to request the words of the cache line in a different order. The processor can communicate which word the program is waiting on, the critical word, and the memory controller can request this word first. Once the word arrives the program can continue while the rest of the cache line arrives and the cache is not yet in a consistent state. This technique is called Critical Word First & Early Restart.

Processors nowadays implement this technique but there are situations when that is not possible. If the processor prefetches data the critical word is not known. Should the processor request the cache line during the time the prefetch operation is in flight it will have to wait until the critical word arrives without being able to influence the order.

Figure 3.30: Critical Word at End of Cache Line

Even with these optimizations in place the position of the critical word on a cache line matters. Figure 3.30 shows the Follow test for sequential and random access. Shown is the slowdown of running the test with the pointer which is chased in the first word versus the case when the pointer is in the last word. The element size is 64 bytes, corresponding the cache line size. The numbers are quite noisy but it can be seen that, as soon as the L2 is not sufficient to hold the working set size, the performance of the case where the critical word is at the end is about 0.7% slower. The sequential access appears to be affected a bit more. This would be consistent with the aforementioned problem when prefetching the next cache line.

3.5.3 Cache Placement

Where the caches are placed in relationship to the hyper-threads, cores, and processors is not under control of the programmer. But programmers can determine where the threads are executed and then it becomes important how the caches relate to the used CPUs.

Here we will not go into details of when to select what cores to run the threads. We will only describe architecture details which the programmer has to take into account when setting the affinity of the threads.

Hyper-threads, by definition share everything but the register set. This includes the L1 caches. There is not much more to say here. The fun starts with the individual cores of a processor. Each core has at least its own L1 caches. Aside from this there are today not many details in common:

• Early multi-core processors had separate L2 caches and no higher caches.

• Later Intel models had shared L2 caches for dual-core processors. For quad-core processors we have to deal with separate L2 caches for each pair of two cores. There are no higher level caches.

• AMD's family 10h processors have separate L2 caches and a unified L3 cache.

A lot has been written in the propaganda material of the processor vendors about the advantage of their respective models. Separate L2 caches have an advantage if the working sets handled by the cores do not overlap. This works well for single-threaded programs. Since this is still often the reality today this approach does not perform too badly. But there is always some overlap. The caches all contain the most actively used parts of the common runtime libraries which means some cache space is wasted.

Completely sharing all caches beside L1 as Intel's dual-core processors do can have a big advantage. If the working set of the threads working on the two cores overlaps significantly the total available cache memory is increased and working sets can be bigger without performance degradation. If the working sets do not overlap Intel's Advanced Smart Cache management is supposed to prevent any one core from monopolizing the entire cache.

If both cores use about half the cache for their respective working sets there is some friction, though. The cache constantly has to weigh the two cores' cache use and the evictions performed as part of this rebalancing might be chosen poorly. To see the problems we look at the results of yet another test program.

Figure 3.31: Bandwidth with two Processes

The test program has one process constantly reading or writing, using SSE instructions, a 2MB block of memory. 2MB was chosen because this is half the size of the L2 cache of this Core 2 processor. The process is pinned to one core while a second process is pinned to the other core. This second process reads and writes a memory region of variable size. The graph shows the number of bytes per cycle which are read or written. Four different graphs are shown, one for each combination of the processes reading and writing. The read/write graph is for the background process, which always uses a 2MB working set to write, and the measured process with variable working set to read.

The interesting part of the graph is the part between 2²⁰ and 2²³ bytes. If the L2 cache of the two cores were completely separate we could expect that the performance of all four tests would drop between 2²¹ and 2²² bytes, that means, once the L2 cache is exhausted. As we can see in Figure 3.31 this is not the case. For the cases where the background process is writing this is most visible. The performance starts to deteriorate before the working set size reaches 1MB. The two processes do not share memory and therefore the processes do not cause RFO messages to be generated. These are pure cache eviction problems. The smart cache handling has its problems with the effect that the experienced cache size per core is closer to 1MB than the 2MB per core which are available. One can only hope that, if caches shared between cores remain a feature of upcoming processors, the algorithm used for the smart cache handling will be fixed.

Having a quad-core processor with two L2 caches was just a stop-gap solution before higher-level caches could be introduced. This design provides no significant performance advantage over separate sockets and dual-core processors. The two cores communicate via the same bus which is, at the outside, visible as the FSB. There is no special fast-track data exchange.

The future of cache design for multi-core processors will lie in more layers. AMD's 10h family of processors make the start. Whether we will continue to see lower level caches be shared by a subset of the cores of a processor remains to be seen. The extra levels of cache are necessary since the high-speed and frequently used caches cannot be shared among many cores. The performance would be impacted. It would also require very large caches with high associativity. Both numbers, the cache size and the associativity, must scale with the number of cores sharing the cache. Using a large L3 cache and reasonably-sized L2 caches is a reasonable trade-off. The L3 cache is slower but it is ideally not as frequently used as the L2 cache.

For programmers all these different designs mean complexity when making scheduling decisions. One has to know the workloads and the details of the machine architecture to achieve the best performance. Fortunately we have support to determine the machine architecture. The interfaces will be introduced in later sections.

3.5.4 FSB Influence

The FSB plays a central role in the performance of the machine. Cache content can only be stored and loaded as quickly as the connection to the memory allows. We can show how much so by running a program on two machines which only differ in the speed of their memory modules. Figure 3.32 shows the results of the Addnext0 test (adding the content of the next elements pad[0] element to the own pad[0] element) for NPAD=7 on a 64-bit machine. Both machines have Intel Core 2 processors, the first uses 667MHz DDR2 modules, the second 800MHz modules (a 20% increase).

Figure 3.32: Influence of FSB Speed

The numbers show that, when the FSB is really stressed for large working set sizes, we indeed see a large benefit. The maximum performance increase measured in this test is 18.2%, close to the theoretical maximum. What this shows is that a faster FSB indeed can pay off big time. It is not critical when the working set fits into the caches (and these processors have a 4MB L2). It must be kept in mind that we are measuring one program here. The working set of a system comprises the memory needed by all concurrently running processes. This way it is easily possible to exceed 4MB memory or more with much smaller programs.

Today some of Intel's processors support FSB speeds up to 1,333MHz which would mean another 60% increase. The future is going to see even higher speeds. If speed is important and the working set sizes are larger, fast RAM and high FSB speeds are certainly worth the money. One has to be careful, though, since even though the processor might support higher FSB speeds the motherboard/Northbridge might not. It is critical to check the specifications.

Continue to Part 3 (virtual memory).

Comments (66 posted)

Page editor: Jonathan Corbet

Security

What chroot() is really for

The chroot() system call is often misunderstood, as it can appear to do much more than it actually does. The confusion arises because it appears to some to be a security tool – there are limited security uses – when it is meant as a tool for isolating processes for installation, debugging, and legacy library usage.

What chroot() actually does is fairly simple, it modifies pathname lookups for a process and its children so that any reference to a path starting '/' will effectively have the new root, which is passed as the single argument, prepended onto the path. The current working directory is left unchanged and relative paths can still refer to files outside of the new root.

Calls to chroot() do not stack, with additional calls essentially overwriting the existing one. It can only be called by privileged programs and can be trivially bypassed by those who can call it as man 2 chroot describes:

    This  call does not change the current working directory, so that after
    the call '.' can be outside the tree rooted at '/'.  In particular, the
    superuser  can  escape from a 'chroot jail' by doing 'mkdir foo; chroot
    foo; cd ..'.

The use of the term "chroot jail" in the manpage is unfortunate as it may help perpetuate a common misconception about chroot(). It often gets mentioned in the same context as the "jail" calls for the BSDs, but it has little in common with them. A BSD jail is a mini-virtualization that partitions a system into multiple virtual systems each of which can have its own root account. chroot() has none of that sophistication.

A patch posted to the linux-kernel mailing list was aimed at fixing the "hole" described in the manpage, but led, instead, to a rather contentious thread. The patch changes chroot() by setting the current working directory to the new root if it was not already somewhere underneath it. This violates POSIX and other standards, which specify the current behavior, as well as numerous typical use cases for chroot(). In addition, as was forcefully pointed out in the thread, there are innumerable ways for a privileged process to access files that are not underneath the new root. Even if it did not run afoul of the standards, there is no point in fixing something that is so trivially bypassed in other ways.

The proponents of fixing the problem that they see – even if most of the kernel hackers disagree – seem to believe that, while you can circumvent a chroot() call, it should not be possible by using chroot() itself. It is an argument that didn't seem to get anywhere for a pretty simple reason: chroot() is not meant to be a security-oriented access control mechanism. It is, instead, a way to run processes with a partitioned view of the filesystem.

There are reasonable uses of chroot() for very limited security purposes. Daemons that do not run as root can be placed into their own filesystem subtree – bind/named and Apache are sometimes run this way – to prevent any access outside of it. That will work, even if the daemon gets exploited, as long as there is no way to elevate privileges after the exploit. For example, if there are vulnerable setuid() programs accessible from within the chroot(), full filesystem access is possible.

chroot() is a useful call, many install programs use it, as do programs that need to see a consistent set of older libraries, but it has very limited use in security applications. It does not provide a sandbox that can be used to test suspicious code, that code might escalate its privilege and access anything it wished. Maintaining an up-to-date chroot() environment adds an additional burden on administrators as well; update tools do nothing to help keep utilities secure if they live outside of the normal places. It is probably safest to avoid using it as any kind of security tool.

Comments (27 posted)

New vulnerabilities

bugzilla: multiple vulnerabilities

Package(s):	bugzilla	CVE #(s):	CVE-2007-4543 CVE-2007-4538 CVE-2007-4539
Created:	October 1, 2007	Updated:	October 3, 2007
Description:	Masahiro Yamada found that from the 2.17.1 version, Bugzilla does not properly sanitize the content of the "buildid" parameter when filing bugs (CVE-2007-4543). The next two vulnerabilities only affect Bugzilla 2.23.3 or later, hence the stable Gentoo Portage tree does not contain these two vulnerabilities: Loic Minier reported that the "Email::Send::Sendmail()" function does not properly sanitise "from" email information before sending it to the "-f" parameter of /usr/sbin/sendmail (CVE-2007-4538), and Frédéric Buclin discovered that the XML-RPC interface does not correctly check permissions in the time-tracking fields (CVE-2007-4539).
Alerts:	Gentoo 200709-18 2007-09-30

Comments (1 posted)

kernel: ALSA returns incorrect write size

Package(s):	kernel	CVE #(s):	CVE-2007-4571
Created:	September 28, 2007	Updated:	June 20, 2008
Description:	The snd_mem_proc_read function in sound/core/memalloc.c in the Advanced Linux Sound Architecture (ALSA) in the Linux kernel before 2.6.22.8 does not return the correct write size, which allows local users to obtain sensitive information (kernel memory contents) via a small count argument, as demonstrated by multiple reads of /proc/driver/snd-page-alloc.
Alerts:	Ubuntu USN-618-1 2008-06-19 Debian DSA-1505 2008-02-22 Debian DSA-1479 2008-01-29 Red Hat RHSA-2007:0993-01 2007-11-29 Red Hat RHSA-2007:0939-01 2007-11-01 SuSE SUSE-SA:2007:053 2007-10-12 Fedora FEDORA-2007-714 2007-10-08 Fedora FEDORA-2007-2349 2007-09-28 rPath rPSA-2007-0202-1 2007-09-27

Comments (none posted)

mplayer: heap-based buffer overflow

Package(s):	mplayer	CVE #(s):	CVE-2007-4938
Created:	October 2, 2007	Updated:	October 3, 2007
Description:	A heap-based buffer overflow in libmpdemux/aviheader.c in MPlayer 1.0rc1 and earlier allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a .avi file with certain large "indx truck size" and nEntriesInuse values, and a certain wLongsPerEntry value.
Alerts:	Mandriva MDKSA-2007:192 2007-10-01

Comments (none posted)

openssl: off-by-one error

Package(s):	openssl	CVE #(s):	CVE-2007-5135
Created:	October 3, 2007	Updated:	July 31, 2008
Description:	From the Debian advisory: An off-by-one error has been identified in the SSL_get_shared_ciphers() routine in the libssl library from OpenSSL, an implementation of Secure Socket Layer cryptographic libraries and utilities. This error could allow an attacker to crash an application making use of OpenSSL's libssl library, or potentially execute arbitrary code in the security context of the user running such an application.
Alerts:	rPath rPSA-2008-0241-1 2008-07-30 SuSE SUSE-SR:2008:005 2008-03-06 Red Hat RHSA-2007:1003-02 2007-11-15 Red Hat RHSA-2007:0813-01 2007-10-22 Fedora FEDORA-2007-2530 2007-10-18 Fedora FEDORA-2007-725 2007-10-15 SuSE SUSE-SR:2007:020 2007-10-12 Red Hat RHSA-2007:0964-01 2007-10-12 Debian DSA-1379-2 2007-10-10 Gentoo 200710-06 2007-10-07 Mandriva MDKSA-2007:193 2007-10-04 rPath rPSA-2007-0206-1 2007-10-03 Foresight FLEA-2007-0058-1 2007-10-03 Debian DSA-1379 2007-10-02

Comments (none posted)

pidgin: denial of service

Package(s):	pidgin	CVE #(s):	CVE-2007-4996
Created:	October 3, 2007	Updated:	November 2, 2007
Description:	Pidgin can be forced to crash by an MSN user sending "nudge" messages.
Alerts:	Fedora FEDORA-2007-2368 2007-10-03 Slackware SSA:2007-275-01 2007-10-03 Foresight FLEA-2007-0057-1 2007-10-02

Comments (1 posted)

Updated vulnerabilities

acroread: multiple vulnerabilities

Package(s):	acroread	CVE #(s):	CVE-2006-5857 CVE-2007-0045 CVE-2007-0046
Created:	January 11, 2007	Updated:	October 26, 2009
Description:	Adobes acrobat reader has the following vulnerabilities: The Adobe Reader Plugin has a cross site scripting vulnerability that can be triggered by processes malformed URLs. Arbitrary JavaScript can be served by a malicious web server, leading to a cross-site scripting attack. Maliciously crafted PDF files can be used to trigger two vulnerabilities, if an attacker can trick a user into viewing the files, arbitrary code can be executed with the user's privileges.
Alerts:	SuSE SUSE-SA:2009:049 2009-10-26 Gentoo 200910-03 2009-10-25 Red Hat RHSA-2007:0021-01 2007-01-22 Gentoo 200701-16 2007-01-22 SuSE SUSE-SA:2007:011 2007-01-22 Red Hat RHSA-2007:0017-01 2007-01-11

Comments (1 posted)

apache2: information disclosure

Package(s):	apache	CVE #(s):	CVE-2007-1862
Created:	June 20, 2007	Updated:	February 18, 2008
Description:	From the Mandriva advisory: "The recall_headers function in mod_mem_cache in Apache 2.2.4 does not properly copy all levels of header data, which can cause Apache to return HTTP headers containing previously-used data, which could be used to obtain potentially sensitive information by unauthorized users."
Alerts:	Fedora FEDORA-2008-1711 2008-02-15 Fedora FEDORA-2007-0704 2007-06-26 Mandriva MDKSA-2007:127 2007-06-19

Comments (2 posted)

apache: multiple vulnerabilities

Package(s):	apache	CVE #(s):	CVE-2007-3304 CVE-2006-5752
Created:	June 27, 2007	Updated:	February 18, 2008
Description:	The Apache HTTP Server did not verify that a process was an Apache child process before sending it signals. A local attacker who has the ability to run scripts on the Apache HTTP Server could manipulate the scoreboard and cause arbitrary processes to be terminated, which could lead to a denial of service. (CVE-2007-3304) A flaw was found in the Apache HTTP Server mod_status module. Sites with the server-status page publicly accessible and ExtendedStatus enabled were vulnerable to a cross-site scripting attack. On Red Hat Enterprise Linux the server-status page is not enabled by default and it is best practice to not make this publicly available. (CVE-2006-5752)
Alerts:	Fedora FEDORA-2008-1711 2008-02-15 SuSE SUSE-SA:2007:061 2007-11-19 Fedora FEDORA-2007-2214 2007-09-18 rPath rPSA-2007-0182-1 2007-09-14 Ubuntu USN-499-1 2007-08-16 Red Hat RHSA-2007:0662-01 2007-07-13 Red Hat RHSA-2007:0557-01 2007-07-13 Fedora FEDORA-2007-615 2007-07-12 Mandriva MDKSA-2007:142 2007-07-04 Mandriva MDKSA-2007:141 2007-07-04 Mandriva MDKSA-2007:140 2007-07-04 Fedora FEDORA-2007-617 2007-07-02 rPath rPSA-2007-0136-1 2007-06-27 Red Hat RHSA-2007:0556-01 2007-06-26 Red Hat RHSA-2007:0534-01 2007-06-26 Red Hat RHSA-2007:0533-01 2007-06-27 Red Hat RHSA-2007:0532-01 2007-06-26

Comments (1 posted)

apache: cross-site scripting

Package(s):	apache	CVE #(s):	CVE-2006-3918
Created:	August 9, 2006	Updated:	April 4, 2008
Description:	From the Red Hat advisory: "A bug was found in Apache where an invalid Expect header sent to the server was returned to the user in an unescaped error message. This could allow an attacker to perform a cross-site scripting attack if a victim was tricked into connecting to a site and sending a carefully crafted Expect header."
Alerts:	SuSE SUSE-SA:2008:021 2008-04-04 Ubuntu USN-575-1 2008-02-04 SuSE SUSE-SA:2006:051 2006-09-08 Debian DSA-1167-1 2005-09-04 Red Hat RHSA-2006:0619-01 2006-08-10 Red Hat RHSA-2006:0618-01 2006-08-08

Comments (none posted)

httpd: denial of service, cross-site scripting

Package(s):	apache httpd	CVE #(s):	CVE-2007-3847 CVE-2007-4465
Created:	September 25, 2007	Updated:	February 15, 2008
Description:	A flaw was found in the mod_proxy module. On sites where a reverse proxy is configured, a remote attacker could send a carefully crafted request that would cause the Apache child process handling that request to crash. On sites where a forward proxy is configured, an attacker could cause a similar crash if a user could be persuaded to visit a malicious site using the proxy. This could lead to a denial of service if using a threaded Multi-Processing Module. (CVE-2007-3847) A flaw was found in the mod_autoindex module. On sites where directory listings are used, and the AddDefaultCharset directive has been removed from the configuration, a cross-site-scripting attack may be possible against browsers which do not correctly derive the response character set following the rules in RFC 2616. (CVE-2007-4465)
Alerts:	Slackware SSA:2008-045-02 2008-02-15 Ubuntu USN-575-1 2008-02-04 Red Hat RHSA-2008:0008-01 2008-01-15 Red Hat RHSA-2008:0006-01 2008-01-15 Red Hat RHSA-2008:0005-01 2008-01-15 Red Hat RHSA-2008:0004-01 2008-01-15 Mandriva MDKSA-2007:235 2007-12-03 SuSE SUSE-SA:2007:061 2007-11-19 Red Hat RHSA-2007:0747-02 2007-11-15 Gentoo 200711-06 2007-11-07 Red Hat RHSA-2007:0746-04 2007-11-07 Red Hat RHSA-2007:0911-01 2007-10-25 Fedora FEDORA-2007-707 2007-09-24

Comments (none posted)

avahi: denial of service

Package(s):	avahi	CVE #(s):	CVE-2007-3372
Created:	June 28, 2007	Updated:	December 23, 2008
Description:	Avahi is vulnerable to a local denial of service that can be caused by making an erroneous call to the assert() function.
Alerts:	Debian DSA-1690-1 2008-12-22 Ubuntu USN-696-1 2008-12-18 Mandriva MDKSA-2007:185 2007-09-17 Foresight FLEA-2007-0030-1 2007-06-28

Comments (none posted)

bochs: buffer overflow

Package(s):	bochs	CVE #(s):	CVE-2007-2893
Created:	July 20, 2007	Updated:	November 19, 2007
Description:	A heap-based buffer overflow in the bx_ne2k_c::rx_frame function in iodev/ne2k.cc in the emulated NE2000 device in Bochs 2.3 allows local users of the guest operating system to write to arbitrary memory locations and gain privileges on the host operating system via vectors that cause TXCNT register values to exceed the device memory size, aka "RX Frame heap overflow."
Alerts:	Gentoo 200711-21 2007-11-17 Fedora FEDORA-2007-1778 2007-08-23 Debian DSA-1351-1 2007-08-07 Fedora FEDORA-2007-1153 2007-07-19

Comments (none posted)

bugzilla: unauthorized account creation

Package(s):	bugzilla	CVE #(s):	CVE-2007-5038
Created:	September 25, 2007	Updated:	September 26, 2007
Description:	The offer_account_by_email function in User.pm in the WebService for Bugzilla before 3.0.2, and 3.1.x before 3.1.2, does not check the value of the createemailregexp parameter, which allows remote attackers to bypass intended restrictions on account creation.
Alerts:	Fedora FEDORA-2007-2299 2007-09-25

Comments (1 posted)

cacti: denial of service

Package(s):	cacti	CVE #(s):	CVE-2007-3112 CVE-2007-3113
Created:	September 18, 2007	Updated:	December 16, 2009
Description:	A vulnerability in Cacti 0.8.6i and earlier versions allows remote authenticated users to cause a denial of service (CPU consumption) via large values of the graph_start, graph_end, graph_height, or graph_width parameters.
Alerts:	Debian DSA-1954-1 2009-12-16 Fedora FEDORA-2008-1737 2008-02-15 Fedora FEDORA-2007-3683 2007-11-22 Fedora FEDORA-2007-2199 2007-09-18 Mandriva MDKSA-2007:184 2007-09-17

Comments (none posted)

centericq: buffer overflows

Package(s):	centericq	CVE #(s):	CVE-2007-3713
Created:	July 20, 2007	Updated:	December 17, 2007
Description:	Multiple buffer overflows in Konst CenterICQ 4.9.11 through 4.21 allow remote attackers to execute arbitrary code via unspecified vectors. NOTE: the provenance of this information is unknown; the details are obtained solely from third party information. NOTE: this might overlap CVE-2007-0160.
Alerts:	Debian DSA-1433-1 2007-12-16 Debian-Testing DTSA-55-1 2007-09-03 Fedora FEDORA-2007-1160 2007-07-19

Comments (none posted)

clamav: denial of service

Package(s):	clamav	CVE #(s):	CVE-2007-3725
Created:	July 24, 2007	Updated:	February 27, 2008
Description:	A NULL pointer dereference has been discovered in the RAR VM of Clam Antivirus (ClamAV) which allows user-assisted remote attackers to cause a denial of service via a specially crafted RAR archives.
Alerts:	SuSE SUSE-SR:2007:015 2007-08-03 Gentoo 200708-04 2007-08-09 Mandriva MDKSA-2007:150 2007-07-25 Debian DSA-1340-1 2007-07-24

Comments (none posted)

clamav: multiple vulnerabilities

Package(s):	clamav	CVE #(s):	CVE-2007-4510 CVE-2007-4560
Created:	September 3, 2007	Updated:	February 13, 2008
Description:	Several remote vulnerabilities have been discovered in the Clam anti-virus toolkit. The Common Vulnerabilities and Exposures project identifies the following problems: CVE-2007-4510: It was discovered that the RTF and RFC2397 parsers can be tricked into dereferencing a NULL pointer, resulting in denial of service. CVE-2007-4560: It was discovered clamav-milter performs insufficient input sanitizing, resulting in the execution of arbitrary shell commands.
Alerts:	Fedora FEDORA-2008-1608 2008-02-13 Fedora FEDORA-2008-0170 2008-01-22 Gentoo 200709-14 2007-09-20 Fedora FEDORA-2007-2050 2007-09-07 Mandriva MDKSA-2007:172 2007-08-31 Debian DSA-1366-1 2007-09-01

Comments (none posted)

cpio: arbitrary code execution

Package(s):	cpio	CVE #(s):	CVE-2005-4268
Created:	January 2, 2006	Updated:	March 17, 2010
Description:	Richard Harms discovered that cpio did not sufficiently validate file properties when creating archives. Files with e. g. a very large size caused a buffer overflow. By tricking a user or an automatic backup system into putting a specially crafted file into a cpio archive, a local attacker could probably exploit this to execute arbitrary code with the privileges of the target user (which is likely root in an automatic backup system).
Alerts:	CentOS CESA-2010:0145 2010-03-17 Red Hat RHSA-2010:0145-01 2010-03-15 rPath rPSA-2007-0094-1 2007-05-07 Red Hat RHSA-2007:0245-02 2007-05-01 Ubuntu USN-234-1 2006-01-02

Comments (none posted)

vixie-cron: privilege escalation

Package(s):	cron	CVE #(s):	CVE-2006-2607
Created:	May 31, 2006	Updated:	June 1, 2009
Description:	The Vixie cron daemon does not check the return code from setuid(); if that call can be made to fail, a local attacker may be able to execute commands as root.
Alerts:	Ubuntu USN-778-1 2009-06-01 Red Hat RHSA-2006:0539-01 2006-07-12 Gentoo 200606-07 2006-06-09 SuSE SUSE-SA:2006:027 2006-05-31 rPath rPSA-2006-0082-1 2006-05-25

Comments (1 posted)

cscope: buffer overflows

Package(s):	cscope	CVE #(s):	CVE-2006-4262
Created:	October 2, 2006	Updated:	June 16, 2009
Description:	Will Drewry of the Google Security Team discovered several buffer overflows in cscope, a source browsing tool, which might lead to the execution of arbitrary code.
Alerts:	CentOS CESA-2009:1101 2009-06-16 Red Hat RHSA-2009:1101-01 2009-06-15 Gentoo 200610-08 2006-10-20 Debian DSA-1186-1 2006-09-30

Comments (none posted)

cscope: buffer overflows

Package(s):	cscope	CVE #(s):	CVE-2004-2541
Created:	May 22, 2006	Updated:	June 19, 2009
Description:	A buffer overflow in Cscope 15.5, and possibly multiple overflows, allows remote attackers to execute arbitrary code via a C file with a long #include line that is later browsed by the target.
Alerts:	CentOS CESA-2009:1102 2009-06-19 CentOS CESA-2009:1101 2009-06-16 Red Hat RHSA-2009:1102-01 2009-06-15 Red Hat RHSA-2009:1101-01 2009-06-15 Gentoo 200606-10 2006-06-11 Debian DSA-1064-1 2006-05-19

Comments (1 posted)

cups: denial of service

Package(s):	cups	CVE #(s):	CVE-2007-0720
Created:	March 26, 2007	Updated:	February 7, 2008
Description:	Previous versions of the cups package could be forced to hang via a client "partially negotiating" an ssl connection. In this state, cups would not allow other connections to be made, a denial of service.
Alerts:	Mandriva MDVSA-2008:036 2007-02-06 Mandriva MDKSA-2007:086 2007-04-16 Red Hat RHSA-2007:0123-01 2007-04-16 Gentoo 200703-28 2007-03-31 Foresight FLEA-2007-0003-1 2007-03-25

Comments (none posted)

gpdf: integer overflow

Package(s):	cups poppler xpdf	CVE #(s):	CVE-2007-3387
Created:	July 31, 2007	Updated:	November 28, 2007
Description:	The gpdf library contains an integer overflow which can be exploited via a malicious PDF file. This code finds its way into multiple packages, including xpdf, kpdf, poppler, cups, and more.
Alerts:	Fedora FEDORA-2007-3390 2007-11-20 Fedora FEDORA-2007-3308 2007-11-20 Gentoo 200710-20 2007-10-18 Gentoo 200710-08 2007-10-09 Gentoo 200709-12 2007-09-19 Fedora FEDORA-2007-685 2007-08-30 Debian-Testing DTSA-54-1 2007-08-22 Fedora FEDORA-2007-669 2007-08-13 Fedora FEDORA-2007-644 2007-08-13 Debian DSA-1357-1 2007-08-19 Mandriva MDKSA-2007:162 2007-08-14 Mandriva MDKSA-2007:165 2007-08-15 Foresight FLEA-2007-0046-1 2007-08-14 Fedora FEDORA-2007-1614 2007-08-15 Mandriva MDKSA-2007:164 2007-08-14 Mandriva MDKSA-2007:163 2007-08-14 Foresight FLEA-2007-0045-1 2007-08-14 Foresight FLEA-2007-0044-1 2007-08-14 Mandriva MDKSA-2007:158 2007-08-13 Mandriva MDKSA-2007:160 2007-08-13 Mandriva MDKSA-2007:161 2007-08-13 Mandriva MDKSA-2007:159 2007-08-13 Fedora FEDORA-2007-1594 2007-08-13 Debian DSA-1355-1 2007-08-13 Slackware SSA:2007-222-05 2007-08-13 Slackware SSA:2007-222-02 2007-08-13 Fedora FEDORA-2007-1547 2007-08-10 Fedora FEDORA-2007-1541 2007-08-10 Debian DSA-1354-1 2007-08-13 rPath rPSA-2007-0154-1 2007-08-10 SuSE SUSE-SR:2007:016 2007-08-10 Ubuntu USN-496-2 2007-08-07 Debian DSA-1352-1 2007-08-07 Debian DSA-1350-1 2007-08-06 Debian DSA-1349-1 2007-08-05 Debian DSA-1348-1 2007-08-04 Debian DSA-1347-1 2007-08-04 SuSE SUSE-SR:2007:015 2007-08-03 Ubuntu USN-496-1 2007-08-03 Red Hat RHSA-2007:0731-01 2007-08-01 Red Hat RHSA-2007:0735-01 2007-07-30 Red Hat RHSA-2007:0732-01 2007-07-30 Red Hat RHSA-2007:0729-01 2007-07-30 Red Hat RHSA-2007:0730-01 2007-07-30 Red Hat RHSA-2007:0720-01 2007-07-30

Comments (1 posted)

dovecot: privilege escalation

Package(s):	dovecot	CVE #(s):	CVE-2007-4211
Created:	August 15, 2007	Updated:	May 21, 2008
Description:	From the rPath advisory: "Previous versions of the dovecot package are vulnerable to a minor privilege escalation attack in which an authenticated user may exploit an ACL plugin weakness to save message flags without having proper permissions."
Alerts:	Red Hat RHSA-2008:0297-02 2008-05-21 Fedora FEDORA-2007-664 2007-08-20 rPath rPSA-2007-0161-1 2007-08-14

Comments (none posted)

dovecot: directory traversal

Package(s):	dovecot	CVE #(s):	CVE-2007-2231
Created:	May 8, 2007	Updated:	May 21, 2008
Description:	Directory traversal vulnerability in index/mbox/mbox-storage.c in Dovecot before 1.0.rc29, when using the zlib plugin, allows remote attackers to read arbitrary gzipped (.gz) mailboxes (mbox files) via a .. (dot dot) sequence in the mailbox name.
Alerts:	Red Hat RHSA-2008:0297-02 2008-05-21 Debian DSA-1359-1 2007-08-28 Ubuntu USN-487-1 2007-07-17 Fedora FEDORA-2007-493 2007-05-07

Comments (none posted)

eggdrop: stack-based buffer overflow

Package(s):	eggdrop	CVE #(s):	CVE-2007-2807
Created:	September 7, 2007	Updated:	December 8, 2009
Description:	A stack-based buffer overflow in mod/server.mod/servrmsg.c in Eggdrop 1.6.18, and possibly earlier, allows user-assisted, malicious remote IRC servers to execute arbitrary code via a long private message.
Alerts:	Mandriva MDVSA-2009:126-1 2009-12-08 Debian DSA-1826-1 2009-07-04 Mandriva MDVSA-2009:126 2009-06-01 Fedora FEDORA-2009-5572 2009-05-28 Fedora FEDORA-2009-5568 2009-05-28 Debian DSA-1448-1 2008-01-05 Fedora FEDORA-2007-4325 2007-12-10 Fedora FEDORA-2007-4305 2007-12-10 Gentoo 200709-07 2007-09-15 Mandriva MDKSA-2007:175 2007-09-06

Comments (none posted)

elinks: remote data sniffing

Package(s):	elinks	CVE #(s):	CVE-2007-5034
Created:	September 25, 2007	Updated:	October 9, 2007
Description:	ELinks before 0.11.3, when sending a POST request for an https URL, appends the body and content headers of the POST request to the CONNECT request in cleartext, which allows remote attackers to sniff sensitive data that would have been protected by TLS. NOTE: this issue only occurs when a proxy is defined for https.
Alerts:	Fedora FEDORA-2007-710 2007-10-08 rPath rPSA-2007-0209-1 2007-10-05 Red Hat RHSA-2007:0933-01 2007-10-03 Debian DSA-1380-1 2007-10-02 Ubuntu USN-519-1 2007-09-25 Fedora FEDORA-2007-2224 2007-09-24

Comments (none posted)

elinks: code execution

Package(s):	elinks	CVE #(s):	CVE-2007-2027
Created:	May 7, 2007	Updated:	October 30, 2009
Description:	Arnaud Giersch discovered that elinks incorrectly attempted to load gettext catalogs from a relative path. If a user were tricked into running elinks from a specific directory, a local attacker could execute code with user privileges.
Alerts:	Red Hat RHSA-2009:1471-01 2009-10-01 CentOS CESA-2009:1471 2009-10-06 CentOS CESA-2009:1471 2009-10-30 Gentoo 200706-03 2007-06-06 Ubuntu USN-457-1 2007-05-07

Comments (none posted)

elinks: arbitrary file access

Package(s):	elinks	CVE #(s):	CVE-2006-5925
Created:	November 16, 2006	Updated:	October 22, 2009
Description:	The elinks text-mode browser has an arbitrary file access vulnerability in the Elinks SMB protocol handler. If a user can be tricked into visiting a specially crafted web page, arbitrary files may be read or written with the user's permissions.
Alerts:	Ubuntu USN-851-1 2009-10-21 Gentoo 200701-27 2007-01-30 OpenPKG OpenPKG-SA-2006.043 2006-12-26 Debian DSA-1240-1 2006-12-21 Gentoo 200612-16 2006-12-14 Debian DSA-1228-1 2006-12-05 Debian DSA-1226-1 2006-12-03 Fedora FEDORA-2006-1278 2006-11-21 Fedora FEDORA-2006-1277 2006-11-21 Mandriva MDKSA-2006:216 2006-11-20 Red Hat RHSA-2006:0742-01 2006-11-15

Comments (none posted)

evolution: format string error

Package(s):	evolution	CVE #(s):	CVE-2007-1002
Created:	March 27, 2007	Updated:	February 27, 2008
Description:	A format string error in the "write_html()" function in calendar/gui/ e-cal-component-memo-preview.c when displaying a memo's categories can potentially be exploited to execute arbitrary code via a specially crafted shared memo containing format specifiers.
Alerts:	SuSE SUSE-SR:2007:015 2007-08-03 Gentoo 200706-02 2007-06-06 Red Hat RHSA-2007:0158-01 2007-05-03 Foresight FLEA-2007-0010-1 2007-04-05 Fedora FEDORA-2007-404 2007-04-04 Fedora FEDORA-2007-393 2007-04-04 Mandriva MDKSA-2007:070 2007-03-27

Comments (1 posted)

evolution-data-server: malicious server arbitrary code execution

Package(s):	evolution-data-server	CVE #(s):	CVE-2007-3257
Created:	June 18, 2007	Updated:	November 7, 2007
Description:	From the GNOME bugzilla: "The "SEQUENCE" value in the GData of the IMAP code (camel-imap-folder.c) is converted from a string using strtol. This allows for negative values. The imap_rescan uses this value as an int. It checks for !seq and seq>summary.length. It doesn't check for seq < 0. Although seq is used as the index of an array."
Alerts:	Gentoo 200711-04 2007-11-06 Gentoo 200707-03 2007-07-02 SuSE SUSE-SA:2007:042 2007-07-05 Debian DSA-1325-1 2007-06-29 Fedora FEDORA-2007-594 2007-06-27 Fedora FEDORA-2007-595 2007-06-27 Mandriva MDKSA-2007:136 2007-06-26 Red Hat RHSA-2007:0510-01 2007-06-25 Red Hat RHSA-2007:0509-01 2007-06-25 Debian DSA-1321-1 2007-06-23 Ubuntu USN-475-1 2007-06-21 Fedora FEDORA-2007-0464 2007-06-16

Comments (1 posted)

pop mail man-in-the-middle attacks

Package(s):	evolution thunderbird mutt fetchmail	CVE #(s):	CVE-2007-1558
Created:	May 8, 2007	Updated:	July 3, 2009
Description:	The APOP protocol allows remote attackers to guess the first 3 characters of a password via man-in-the-middle (MITM) attacks that use crafted message IDs and MD5 collisions. NOTE: this design-level issue potentially affects all products that use APOP, including (1) Thunderbird, (2) Evolution, (3) mutt, and (4) fetchmail.
Alerts:	CentOS CESA-2009:1140 2009-07-02 Red Hat RHSA-2009:1140-02 2009-07-02 Fedora FEDORA-2007-1447 2007-08-06 rPath rPSA-2007-0127-1 2007-06-19 Foresight FLEA-2007-0026-1 2007-06-18 rPath rPSA-2007-0122-1 2007-06-14 Red Hat RHSA-2007:0385-01 2007-06-07 rPath rPSA-2007-0114-1 2007-06-04 Mandriva MDKSA-2007:113 2007-06-04 Red Hat RHSA-2007:0386-01 2007-06-04 Fedora FEDORA-2007-0001 2007-06-01 Fedora FEDORA-2007-552 2007-05-31 Fedora FEDORA-2007-552 2007-05-31 Fedora FEDORA-2007-552 2007-05-31 Fedora FEDORA-2007-552 2007-05-31 Fedora FEDORA-2007-550 2007-05-31 Fedora FEDORA-2007-551 2007-05-31 Red Hat RHSA-2007:0401-01 2007-05-30 Fedora FEDORA-2007-539 2007-05-30 Fedora FEDORA-2007-540 2007-05-30 Red Hat RHSA-2007:0344-01 2007-05-30 Mandriva MDKSA-2007:107 2007-05-19 Mandriva MDKSA-2007:105 2007-05-17 Red Hat RHSA-2007:0353-01 2007-05-17 Fedora FEDORA-2007-484 2007-05-07 Fedora FEDORA-2007-485 2007-05-07

Comments (none posted)

fetchmail: denial of service

Package(s):	fetchmail	CVE #(s):	CVE-2007-4565
Created:	September 5, 2007	Updated:	October 30, 2009
Description:	fetchmail before 6.3.9 allows context-dependent attackers to cause a denial of service (NULL dereference and application crash) by refusing certain warning messages that are sent over SMTP.
Alerts:	CentOS CESA-2009:1427 2009-09-08 Red Hat RHSA-2009:1427-01 2009-09-08 CentOS CESA-2009:1427 2009-10-30 Ubuntu USN-520-1 2007-09-26 Debian DSA-1377-2 2007-09-21 Debian DSA-1377 2007-09-21 Mandriva MDKSA-2007:179 2007-09-11 Foresight FLEA-2007-0053-1 2007-09-06 rPath rPSA-2007-0178-1 2007-09-05 Fedora FEDORA-2007-1983 2007-09-04 Fedora FEDORA-2007-689 2007-09-04

Comments (none posted)

file: integer overflow

Package(s):	file	CVE #(s):	CVE-2007-2799
Created:	June 1, 2007	Updated:	October 19, 2007
Description:	Colin Percival from FreeBSD reported that the previous fix for the file_printf() buffer overflow introduced a new integer overflow. A remote attacker could entice a user to run the file program on an overly large file (more than 1Gb) that would trigger an integer overflow on 32-bit systems, possibly leading to the execution of arbitrary code with the rights of the user running file.
Alerts:	Gentoo 200710-19 2007-10-18 Debian DSA-1343-2 2007-09-25 Debian DSA-1343-1 2007-07-31 SuSE SUSE-SA:2007:040 2007-07-04 Fedora FEDORA-2007-0836 2007-07-03 Fedora FEDORA-2007-538 2007-06-11 Fedora FEDORA-2007-541 2007-06-11 Ubuntu USN-439-2 2007-06-11 Mandriva MDKSA-2007:114 2007-06-05 Gentoo 200705-25 2007-05-31

Comments (3 posted)

firebird: buffer overflow

Package(s):	firebird	CVE #(s):	CVE-2007-3181
Created:	July 2, 2007	Updated:	March 27, 2008
Description:	The Firebird DBMS has a buffer overflow vulnerability involving the processing of connect requests with an overly large p_cnct_count value. Remote attackers can send a specially crafted request to the server in order to potentially execute arbitrary code with the permissions of the Firebird user.
Alerts:	Debian DSA-1529-1 2008-03-24 Gentoo 200707-01 2007-07-01

Comments (none posted)

firefox: multiple vulnerabilities

Package(s):	firefox	CVE #(s):	CVE-2007-3844 CVE-2007-3845
Created:	August 1, 2007	Updated:	February 20, 2008
Description:	A flaw was discovered in handling of "about:blank" windows used by addons. A malicious web site could exploit this to modify the contents, or steal confidential data (such as passwords), of other web pages. (CVE-2007-3844) Jesper Johansson discovered that spaces and double-quotes were not correctly handled when launching external programs. In rare configurations, after tricking a user into opening a malicious web page, an attacker could execute helpers with arbitrary arguments with the user's privileges. (CVE-2007-3845)
Alerts:	Mandriva MDVSA-2007:047 2007-02-19 Fedora FEDORA-2007-3414 2007-11-16 Fedora FEDORA-2007-3431 2007-11-16 Red Hat RHSA-2007:0981-01 2007-10-19 Red Hat RHSA-2007:0980-01 2007-10-19 Red Hat RHSA-2007:0979-01 2007-10-19 Debian DSA-1391-1 2007-10-19 Gentoo 200708-09 2007-08-14 rPath rPSA-2007-0157-1 2007-08-10 Slackware SSA:2007-215-01 2007-08-06 Debian DSA-1346-1 2007-08-04 Debian DSA-1345-1 2007-08-04 Debian DSA-1344-1 2007-08-03 Foresight FLEA-2007-0040-1 2007-08-03 Slackware SSA:2007-213-01 2007-08-02 Mandriva MDKSA-2007:152 2007-08-01 Foresight FLEA-2007-0039-1 2007-08-01 Ubuntu USN-493-1 2007-07-31

Comments (none posted)

firefox, thunderbird, seamonkey: multiple vulnerabilities

Package(s):	firefox, thunderbird, seamonkey	CVE #(s):	CVE-2007-3738 CVE-2007-3656 CVE-2007-3670 CVE-2007-3285 CVE-2007-3737 CVE-2007-3089 CVE-2007-3736 CVE-2007-3734 CVE-2007-3735
Created:	July 18, 2007	Updated:	May 12, 2008
Description:	shutdown and moz_bug_r_a4 reported two separate ways to modify an XPCNativeWrapper such that subsequent access by the browser would result in executing user-supplied code. (CVE-2007-3738) Michal Zalewski reported that it was possible to bypass the same-origin checks and read from cached (wyciwyg) documents It is possible to access wyciwyg:// documents without proper same domain policy checks through the use of HTTP 302 redirects. This enables the attacker to steal sensitive data displayed on dynamically generated pages; perform cache poisoning; and execute own code or display own content with URL bar and SSL certificate data of the attacked page (URL spoofing++). (CVE-2007-3656) Internet Explorer calls registered URL protocols without escaping quotes and may be used to pass unexpected and potentially dangerous data to the application that registers that URL Protocol. (CVE-2007-3670) Ronald van den Heetkamp reported that a filename URL containing %00 (encoded null) can cause Firefox to interpret the file extension differently than the underlying Windows operating system potentially leading to unsafe actions such as running a program. This is only accessible locally. (CVE-2007-3285) An attacker can use an element outside of a document to call an event handler allowing content to run arbitrary code with chrome privileges. (CVE-2007-3737) Ronen Zilberman and Michal Zalewski both reported that it was possible to exploit a timing issue to inject content into about:blank frames in a page. When opening a window from a script, it is possible to spoof the content of the newly opened window's frames within a short time frame, while the window is loading. (CVE-2007-3089) Mozilla contributor moz_bug_r_a4 demonstrated that the methods addEventListener and setTimeout could be used to inject script into another site in violation of the browser's same-origin policy. This could be used to access or modify private or valuable information from that other site. (CVE-2007-3736) As part of the Firefox 2.0.0.5 update releases Mozilla developers fixed many bugs to improve the stability of the product. Some of these crashes that showed evidence of memory corruption under certain circumstances and we presume that with enough effort at least some of these could be exploited to run arbitrary code. Note: Thunderbird shares the browser engine with Firefox and could be vulnerable if JavaScript were to be enabled in mail. This is not the default setting and we strongly discourage users from running JavaScript in mail. Without further investigation we cannot rule out the possibility that for some of these an attacker might be able to prepare memory for exploitation through some means other than JavaScript, such as large images. (CVE-2007-3734, CVE-2007-3735)
Alerts:	Debian DSA-1574-1 2008-05-12 Debian DSA-1534-2 2008-04-24 Debian DSA-1535-1 2008-03-30 Debian DSA-1534-1 2008-03-28 Debian DSA-1532-1 2008-03-27 Mandriva MDVSA-2007:047 2007-02-19 Ubuntu USN-503-1 2007-08-24 Slackware SSA:2007-222-04 2007-08-13 SuSE SUSE-SA:2007:049 2007-08-02 Slackware SSA:2007-205-02 2007-07-25 Slackware SSA:2007-205-01 2007-07-25 Foresight FLEA-2007-0033-1 2007-07-24 Debian DSA-1339-1 2007-07-23 Debian DSA-1338-1 2007-07-23 Fedora FEDORA-2007-1181 2007-07-20 Fedora FEDORA-2007-1180 2007-07-20 Debian DSA-1337-1 2007-07-22 Fedora FEDORA-2007-642 2007-07-20 Fedora FEDORA-2007-641 2007-07-20 rPath rPSA-2007-0148-1 2007-07-20 Ubuntu USN-490-1 2007-07-19 Slackware SSA:2007-200-01 2007-07-20 Fedora FEDORA-2007-1159 2007-07-19 Fedora FEDORA-2007-1157 2007-07-19 Fedora FEDORA-2007-1155 2007-07-19 Red Hat RHSA-2007:0724-01 2007-07-18 Red Hat RHSA-2007:0723-01 2007-07-18 Red Hat RHSA-2007:0722-01 2007-07-18 Fedora FEDORA-2007-1143 2007-07-18 Fedora FEDORA-2007-1144 2007-07-18 Fedora FEDORA-2007-1142 2007-07-18 Fedora FEDORA-2007-1138 2007-07-18

Comments (none posted)

flac123: arbitrary code execution

Package(s):	flac123	CVE #(s):	CVE-2007-3507
Created:	July 13, 2007	Updated:	October 22, 2007
Description:	A stack-based buffer overflow in the local__vcentry_parse_value function in vorbiscomment.c in flac123 (aka flac-tools or flac) before 0.0.10 allows user-assisted remote attackers to execute arbitrary code via a large comment value_length.
Alerts:	Gentoo 200709-06 2007-09-14 Fedora FEDORA-2007-1045 2007-07-12

Comments (none posted)

freetype: arbitrary code execution

Package(s):	freetype	CVE #(s):	CVE-2007-2754
Created:	May 24, 2007	Updated:	June 1, 2010
Description:	The Freetype font rendering library versions 2.3.4 and below has an integer sign error. Remote attackers may be able to create a specially crafted TrueType Font file with a negative n_points value that will cause an integer overflow and heap-based buffer overflow, allowing the execution of arbitrary code.
Alerts:	Gentoo 201006-01 2010-06-01 Fedora FEDORA-2009-5644 2009-05-28 Fedora FEDORA-2009-5558 2009-05-28 CentOS CESA-2009:0329 2009-05-22 Red Hat RHSA-2009:1062-01 2009-05-22 Red Hat RHSA-2009:0329-02 2009-05-22 Debian DSA-1334 2007-07-18 SuSE SUSE-SA:2007:041 2007-07-04 Fedora FEDORA-2007-561 2007-06-18 Mandriva MDKSA-2007:121 2007-06-13 Foresight FLEA-2007-0025-1 2007-06-13 Red Hat RHSA-2007:0403-01 2007-06-11 Debian DSA-1302-1 2007-06-10 Fedora FEDORA-2007-0033 2007-06-01 Ubuntu USN-466-1 2007-05-30 Gentoo 200705-22 2007-05-30 Trustix TSLSA-2007-0019 2007-05-25 rPath rPSA-2007-0108-1 2007-05-23 Foresight FLEA-2007-0020-1 2007-05-21 OpenPKG OpenPKG-SA-2007.018 2007-05-24

Comments (none posted)

freetype: integer overflows

Package(s):	freetype	CVE #(s):	CVE-2006-0747 CVE-2006-1861 CVE-2006-2493 CVE-2006-2661 CVE-2006-3467
Created:	June 8, 2006	Updated:	June 1, 2010
Description:	The FreeType library has several integer overflow vulnerabilities. If a user can be tricked into installing a specially crafted font file, arbitrary code can be executed with the privilege of the user.
Alerts:	Gentoo 201006-01 2010-06-01 Fedora FEDORA-2009-5644 2009-05-28 Fedora FEDORA-2009-5558 2009-05-28 CentOS CESA-2009:0329 2009-05-22 Red Hat RHSA-2009:1062-01 2009-05-22 Red Hat RHSA-2009:0329-02 2009-05-22 Gentoo 200710-09 2007-10-09 Debian DSA-1178-1 2006-09-16 Ubuntu USN-341-1 2006-09-06 Gentoo 200609-04 2006-09-06 rPath rPSA-2006-0157-1 2006-08-25 Mandriva MDKSA-2006:148 2006-08-24 Red Hat RHSA-2006:0635-01 2006-08-21 Red Hat RHSA-2006:0634-01 2006-08-21 Fedora FEDORA-2006-912 2006-08-14 SuSE SUSE-SA:2006:045 2006-08-01 OpenPKG OpenPKG-SA-2006.017 2006-07-28 Ubuntu USN-324-1 2006-07-27 Slackware SSA:2006-207-02 2006-07-27 Mandriva MDKSA-2006:129 2006-07-20 Gentoo 200607-02 2006-07-09 SuSE SUSE-SA:2006:037 2006-06-27 Mandriva MDKSA-2006:099-1 2006-06-13 Mandriva MDKSA-2006:099 2006-06-12 rPath rPSA-2006-0100-1 2006-06-12 Debian DSA-1095-1 2006-06-10 Ubuntu USN-291-1 2006-06-08

Comments (none posted)

fuse: incorrect file access permissions

Package(s):	fuse	CVE #(s):
Created:	September 26, 2007	Updated:	September 26, 2007
Description:	It was discovered that members of the group fuse can get access to devices which they normally should not have access to. For ntfs-3g mounts, this was because /sbin/mount.ntfs-3g was setuid root. This update fixes /sbin/mount.ntfs-3g so that it is no longer has the setuid bit enabled. The fuse package is also being updated to correct an error in the previous testing package which incorrectly changed the permissions on /dev/fuse.
Alerts:	Fedora FEDORA-2007-2295 2007-09-25

Comments (none posted)

gallery2: multiple unspecified vulnerabilities

Package(s):	gallery2	CVE #(s):	CVE-2007-4650
Created:	September 5, 2007	Updated:	November 9, 2007
Description:	Multiple unspecified vulnerabilities in Gallery before 2.2.3 allow attackers to (1) rename items, (2) read and modify item properties, or (3) lock and replace items via unknown vectors in (a) the WebDAV module; and (4) edit unspecified data files using "linked items" in (a) WebDAV and (b) Reupload modules.
Alerts:	Debian DSA-1404-1 2007-11-08 Gentoo 200711-03 2007-11-01 Fedora FEDORA-2007-2020 2007-09-04

Comments (none posted)

gcc: file overwrite vulnerability

Package(s):	gcc	CVE #(s):	CVE-2006-3619
Created:	September 6, 2006	Updated:	March 14, 2008
Description:	The fastjar utility found in the GNU compiler collection does not perform adequate file path checking, allowing the creation or overwriting of files outside of the current directory tree.
Alerts:	Mandriva MDVSA-2008:066 2007-03-13 Red Hat RHSA-2007:0473-01 2007-06-11 Red Hat RHSA-2007:0220-02 2007-05-01 Debian DSA-1170-1 2006-09-06

Comments (none posted)

gd: buffer overflow

Package(s):	gd	CVE #(s):	CVE-2007-0455
Created:	February 7, 2007	Updated:	November 18, 2009
Description:	The gd graphics library contains a buffer overflow which could enable a remote attacker to execute arbitrary code. Note that various other packages include code from gd and could also be vulnerable.
Alerts:	Debian DSA-1936-1 2009-11-17 Red Hat RHSA-2008:0146-01 2008-02-28 Ubuntu USN-473-1 2007-06-11 OpenPKG OpenPKG-SA-2007.016 2007-05-18 Trustix TSLSA-2007-0007 2007-02-13 Fedora FEDORA-2007-150 2007-02-12 Fedora FEDORA-2007-149 2007-02-12 rPath rPSA-2007-0028-1 2007-02-08 Mandriva MDKSA-2007:038 2006-02-06 Mandriva MDKSA-2007:036 2006-02-06 Mandriva MDKSA-2007:035 2006-02-06

Comments (2 posted)

gd: multiple vulnerabilities

Package(s):	gd	CVE #(s):	CVE-2007-3472 CVE-2007-3473 CVE-2007-3474 CVE-2007-3475 CVE-2007-3476 CVE-2007-3477 CVE-2007-3478
Created:	August 6, 2007	Updated:	November 6, 2009
Description:	Integer overflow in gdImageCreateTrueColor function in the GD Graphics Library (libgd) before 2.0.35 allows user-assisted remote attackers to have unspecified remote attack vectors and impact. (CVE-2007-3472) The gdImageCreateXbm function in the GD Graphics Library (libgd) before 2.0.35 allows user-assisted remote attackers to cause a denial of service (crash) via unspecified vectors involving a gdImageCreate failure. (CVE-2007-3473) Multiple unspecified vulnerabilities in the GIF reader in the GD Graphics Library (libgd) before 2.0.35 allow user-assisted remote attackers to have unspecified attack vectors and impact. (CVE-2007-3474) The GD Graphics Library (libgd) before 2.0.35 allows user-assisted remote attackers to cause a denial of service (crash) via a GIF image that has no global color map. (CVE-2007-3475) Array index error in gd_gif_in.c in the GD Graphics Library (libgd) before 2.0.35 allows user-assisted remote attackers to cause a denial of service (crash and heap corruption) via large color index values in crafted image data, which results in a segmentation fault. (CVE-2007-3476) The (a) imagearc and (b) imagefilledarc functions in GD Graphics Library (libgd) before 2.0.35 allows attackers to cause a denial of service (CPU consumption) via a large (1) start or (2) end angle degree value. (CVE-2007-3477) Race condition in gdImageStringFTEx (gdft_draw_bitmap) in gdft.c in the GD Graphics Library (libgd) before 2.0.35 allows user-assisted remote attackers to cause a denial of service (crash) via unspecified vectors, possibly involving truetype font (TTF) support. (CVE-2007-3478)
Alerts:	Ubuntu USN-854-1 2009-11-05 Debian DSA-1613-1 2008-07-22 Red Hat RHSA-2008:0146-01 2008-02-28 SuSE SUSE-SR:2007:015 2007-08-03 Fedora FEDORA-2007-692 2007-09-18 Fedora FEDORA-2007-2055 2007-09-07 Foresight FLEA-2007-0052-1 2007-09-06 rPath rPSA-2007-0176-1 2007-09-05 Trustix TSLSA-2007-0024 2007-08-10 Gentoo 200708-05 2007-08-09 Mandriva MDKSA-2007:153 2007-08-03

Comments (none posted)

gd: denial of service

Package(s):	gd	CVE #(s):	CVE-2007-2756
Created:	June 14, 2007	Updated:	February 28, 2008
Description:	Libgd2 has a denial of service vulnerability involving the incorrect validation of PNG callback results. If an application that is linked against libgd2 is used to process a specially-crafted PNG file, a denial of service involving CPU resource consumption can be caused.
Alerts:	Red Hat RHSA-2008:0146-01 2008-02-28 Slackware SSA:2007-178-01 2007-06-27 SuSE SUSE-SR:2007:013 2007-06-22 Mandriva MDKSA-2007:124 2007-06-13 Mandriva MDKSA-2007:123 2007-06-13 Mandriva MDKSA-2007:122 2007-06-13

Comments (none posted)

gedit: format string vulnerability

Package(s):	gedit	CVE #(s):	CAN-2005-1686
Created:	June 9, 2005	Updated:	February 5, 2009
Description:	A format string vulnerability has been discovered in gedit. Calling the program with specially crafted file names caused a buffer overflow, which could be exploited to execute arbitrary code with the privileges of the gedit user.
Alerts:	Fedora FEDORA-2009-1189 2009-01-29 Fedora FEDORA-2009-1187 2009-01-29 Debian DSA-753-1 2005-07-12 Mandriva MDKSA-2005:102 2005-06-15 Red Hat RHSA-2005:499-01 2005-06-13 Gentoo 200506-09 2005-06-11 Ubuntu USN-138-1 2005-06-09

Comments (1 posted)

gimp: multiple vulnerabilities

Package(s):	gimp	CVE #(s):	CVE-2007-2949
Created:	June 28, 2007	Updated:	February 27, 2008
Description:	The gimp image editor has several vulnerabilities, including a problem where it can open PSD files with excessive dimensions and a possible stack overflow in the Sunras loader.
Alerts:	SuSE SUSE-SR:2007:015 2007-08-03 Red Hat RHSA-2007:0513-01 2007-09-26 Mandriva MDKSA-2007:170 2007-08-23 Slackware SSA:2007-222-01 2007-08-13 Foresight FLEA-2007-0038-1 2007-08-01 Gentoo 200707-09 2007-07-25 Fedora FEDORA-2007-627 2007-07-16 Debian DSA-1335-1 2007-07-18 Fedora FEDORA-2007-1099 2007-07-16 Fedora FEDORA-2007-1044 2007-07-12 rPath rPSA-2007-0138-1 2007-07-11 Ubuntu USN-480-1 2007-07-04 Fedora FEDORA-2007-618 2007-06-27 Fedora FEDORA-2007-619 2007-06-27 Fedora FEDORA-2007-0725 2007-06-27

Comments (none posted)

openssh: inappropriate use of trusted cookies

Package(s):	gnome-ssh-askpass openssh	CVE #(s):	CVE-2007-4752
Created:	September 11, 2007	Updated:	August 25, 2008
Description:	OpenSSH in versions prior 4.7 could use a trusted X11 cookie if the creation of an untrusted cookie failed.
Alerts:	CentOS CESA-2008:0855 2008-08-22 Red Hat RHSA-2008:0855-01 2008-08-22 Debian DSA-1576-1 2008-05-14 Ubuntu USN-566-1 2008-01-09 Mandriva MDKSA-2007:236 2007-12-04 Gentoo 200711-02 2007-11-01 Fedora FEDORA-2007-715 2007-10-15 Foresight FLEA-2007-0055-1 2007-09-17 Slackware SSA:2007-255-01 2007-09-13 rPath rPSA-2007-0181-1 2007-09-10

Comments (none posted)

grip: buffer overflow

Package(s):	grip	CVE #(s):	CAN-2005-0706
Created:	March 10, 2005	Updated:	November 19, 2008
Description:	Grip, a CD ripper, has a buffer overflow vulnerability that can occur when the CDDB server returns more than 16 matches.
Alerts:	Fedora FEDORA-2008-9604 2008-11-19 Fedora FEDORA-2008-9521 2008-11-19 Fedora-Legacy FLSA:152919 2005-09-15 Mandriva MDKSA-2005:074 2005-04-20 Mandriva MDKSA-2005:075 2005-04-20 Gentoo 200504-07 2005-04-08 Mandrake MDKSA-2005:066 2005-04-01 Red Hat RHSA-2005:304-01 2005-03-28 Gentoo 200503-21 2005-03-17 Fedora FEDORA-2005-203 2005-03-09 Fedora FEDORA-2005-202 2005-03-09

Comments (none posted)

gzip: multiple vulnerabilities

Package(s):	gzip	CVE #(s):	CVE-2006-4334 CVE-2006-4335 CVE-2006-4336 CVE-2006-4337 CVE-2006-4338
Created:	September 19, 2006	Updated:	January 20, 2010
Description:	Tavis Ormandy of the Google Security Team discovered two denial of service flaws in the way gzip expanded archive files. If a victim expanded a specially crafted archive, it could cause the gzip executable to hang or crash. Tavis Ormandy of the Google Security Team discovered several code execution flaws in the way gzip expanded archive files. If a victim expanded a specially crafted archive, it could cause the gzip executable to crash or execute arbitrary code.
Alerts:	Debian DSA-1974-1 2010-01-20 Fedora FEDORA-2007-557 2007-05-31 Gentoo 200611-24 2006-11-28 Fedora-Legacy FLSA:211760 2006-11-13 Fedora FEDORA-2006-989 2006-10-10 SuSE SUSE-SA:2006:056 2006-09-26 Gentoo 200609-13 2006-09-23 Trustix TSLSA-2006-0052 2006-09-22 Mandriva MDKSA-2006:167 2006-09-20 Slackware SSA:2006-262-01 2006-09-20 OpenPKG OpenPKG-SA-2006.020 2006-09-20 Debian DSA-1181-1 2006-09-19 rPath rPSA-2006-0170-1 2006-09-19 Ubuntu USN-349-1 2006-09-19 Red Hat RHSA-2006:0667-01 2006-09-19

Comments (1 posted)

horde-kronolith: local file inclusion

Package(s):	horde-kronolith	CVE #(s):	CVE-2006-6175
Created:	January 17, 2007	Updated:	March 7, 2008
Description:	Kronolith contains a mistake in lib/FBView.php where a raw, unfiltered string is used instead of a sanitized string to view local files. An authenticated attacker could craft an HTTP GET request that uses directory traversal techniques to execute any file on the web server as PHP code, which could allow information disclosure or arbitrary code execution with the rights of the user running the PHP application (usually the webserver user).
Alerts:	Gentoo 200701-11 2007-01-16

Comments (none posted)

id3lib: insecure tmpfile creation

Package(s):	id3lib	CVE #(s):	CVE-2007-4460
Created:	August 27, 2007	Updated:	October 2, 2007
Description:	The RenderV2ToFile function in tag_file.cpp in id3lib (aka libid3) 3.8.3 allows local users to overwrite arbitrary files via a symlink attack on a temporary file whose name is constructed from the name of a file being tagged.
Alerts:	Debian DSA-1365-3 2007-10-02 Gentoo 200709-08 2007-09-15 Mandriva MDKSA-2007:180 2007-09-12 Debian DSA-1365-2 2007-09-09 Debian DSA-1365-1 2007-09-01 Fedora FEDORA-2007-1774 2007-08-23

Comments (none posted)

ImageMagick: integer overflows

Package(s):	imagemagick	CVE #(s):	CVE-2007-1797
Created:	April 4, 2007	Updated:	August 11, 2009
Description:	Multiple integer overflows in ImageMagick before 6.3.3-5 allow remote attackers to execute arbitrary code via (1) a crafted DCM image, which results in a heap-based overflow in the ReadDCMImage function, or (2) the (a) colors or (b) comments field in a crafted XWD image, which results in a heap-based overflow in the ReadXWDImage function, different issues than CVE-2007-1667.
Alerts:	Debian DSA-1858-1 2009-08-10 Red Hat RHSA-2008:0165-01 2008-04-16 Red Hat RHSA-2008:0145-01 2008-04-16 Fedora FEDORA-2007-1340 2007-07-30 Mandriva MDKSA-2007:147 2007-07-20 Ubuntu USN-481-1 2007-07-10 Gentoo 200705-13 2007-05-10 Fedora FEDORA-2007-414 2007-04-17 Fedora FEDORA-2007-413 2007-04-05 rPath rPSA-2007-0064-1 2007-04-04

Comments (none posted)

jasper: denial of service

Package(s):	jasper	CVE #(s):	CVE-2007-2721
Created:	June 1, 2007	Updated:	April 19, 2010
Description:	The jpc_qcx_getcompparms function in jpc/jpc_cs.c could allow remote user-assisted attackers to cause a denial of service (crash) and possibly corrupt the heap via malformed image files.
Alerts:	Debian DSA-2036-1 2010-04-17 Mandriva MDVSA-2009:142-1 2009-12-03 Mandriva MDVSA-2009:164 2009-07-28 Mandriva MDVSA-2009:142 2009-06-26 CentOS CESA-2009:0012 2009-02-11 Red Hat RHSA-2009:0012-01 2009-02-11 Mandriva MDKSA-2007:209 2007-11-05 Mandriva MDKSA-2007:208 2007-11-05 Ubuntu USN-501-2 2007-10-22 Ubuntu USN-501-1 2007-08-20 Mandriva MDKSA-2007:129 2007-06-19 Fedora FEDORA-2007-0001 2007-06-01

Comments (none posted)

java: multiple vulnerabilities

Package(s):	java	CVE #(s):	CVE-2006-4339 CVE-2006-4790 CVE-2006-6731 CVE-2006-6736 CVE-2006-6737 CVE-2006-6745
Created:	January 18, 2007	Updated:	June 4, 2010
Description:	java has multiple vulnerabilities, these include: an RSA exponent padding attack vulnerability, two vulnerabilities which allow untrusted applets to access data in other applets, vulnerabilities that involve applets gaining privileges due to serialization bugs in the JRE and buffer overflows in the java image handling routines that can give attackers read/write/execute capabilities for local files.
Alerts:	Pardus 2010-67 2010-06-04 Gentoo 200705-20 2007-05-26 Red Hat RHSA-2007:0073-01 2007-02-09 Red Hat RHSA-2007:0072-01 2007-02-08 Red Hat RHSA-2007:0062-02 2007-02-07 Gentoo 200701-15 2007-01-22 SuSE SUSE-SA:2007:010 2007-01-18

Comments (1 posted)

java-1.5.0-sun: multiple vulnerabilities

Package(s):	java-1.5.0-sun	CVE #(s):	CVE-2007-3503 CVE-2007-3655 CVE-2007-3698 CVE-2007-3922
Created:	August 6, 2007	Updated:	June 24, 2008
Description:	The Javadoc tool was able to generate HTML documentation pages that contained cross-site scripting (XSS) vulnerabilities. A remote attacker could use this to inject arbitrary web script or HTML. (CVE-2007-3503) The Java Web Start URL parsing component contained a buffer overflow vulnerability within the parsing code for JNLP files. A remote attacker could create a malicious JNLP file that could trigger this flaw and execute arbitrary code when opened. (CVE-2007-3655) The JSSE component did not correctly process SSL/TLS handshake requests. A remote attacker who is able to connect to a JSSE-based service could trigger this flaw leading to a denial-of-service. (CVE-2007-3698) A flaw was found in the applet class loader. An untrusted applet could use this flaw to circumvent network access restrictions, possibly connecting to services hosted on the machine that executed the applet. (CVE-2007-3922)
Alerts:	Red Hat RHSA-2008:0133-01 2008-06-24 SuSE SUSE-SA:2008:025 2008-04-25 Gentoo 200804-20 2008-04-17 Red Hat RHSA-2008:0132-01 2008-02-14 Red Hat RHSA-2007:1086-01 2007-12-12 SuSE SUSE-SA:2007:056 2007-10-18 Red Hat RHSA-2007:0956-01 2007-10-16 Slackware SSA:2007-243-01 2007-08-31 Red Hat RHSA-2007:0829-01 2007-08-07 Red Hat RHSA-2007:0818-01 2007-08-06

Comments (none posted)

JRockit: multiple vulnerabilities

Package(s):	jrockit-jdk-bin	CVE #(s):	CVE-2007-2788 CVE-2007-4381 CVE-2007-3716 CVE-2007-2789 CVE-2007-3004 CVE-2007-3005 CVE-2007-3503 CVE-2007-3698 CVE-2007-3922
Created:	September 24, 2007	Updated:	June 24, 2008
Description:	An integer overflow vulnerability exists in the embedded ICC profile image parser (CVE-2007-2788), an unspecified vulnerability exists in the font parsing implementation (CVE-2007-4381), and an error exists when processing XSLT stylesheets contained in XSLT Transforms in XML signatures (CVE-2007-3716), among other vulnerabilities.
Alerts:	Red Hat RHSA-2008:0133-01 2008-06-24 SuSE SUSE-SA:2008:025 2008-04-25 Gentoo 200804-20 2008-04-17 Red Hat RHSA-2008:0100-01 2008-03-11 Red Hat RHSA-2008:0132-01 2008-02-14 Red Hat RHSA-2007:1086-01 2007-12-12 Gentoo 200709-15 2007-09-23

Comments (none posted)

kdebase: several vulnerabilities

Package(s):	kdebase	CVE #(s):	CVE-2007-3820 CVE-2007-4224 CVE-2007-4225
Created:	August 20, 2007	Updated:	October 8, 2007
Description:	konqueror/konq_combo.cc in Konqueror 3.5.7 allows remote attackers to spoof the data: URI scheme in the address bar via a long URI with trailing whitespace, which prevents the beginning of the URI from being displayed. (CVE-2007-3820) KDE Konqueror 3.5.7 allows remote attackers to spoof the URL address bar by calling setInterval with a small interval and changing the window.location property. (CVE-2007-4224) Visual truncation vulnerability in KDE Konqueror 3.5.7 allows remote attackers to spoof the URL address bar via an http URI with a large amount of whitespace in the user/password portion. (CVE-2007-4225)
Alerts:	Red Hat RHSA-2007:0909-01 2007-10-08 Red Hat RHSA-2007:0905-01 2007-10-08 Fedora FEDORA-2007-716 2007-10-08 Mandriva MDKSA-2007:176 2007-09-06 rPath rPSA-2007-0177-1 2007-09-05 Ubuntu USN-502-1 2007-08-23 Fedora FEDORA-2007-1699 2007-08-20 Fedora FEDORA-2007-1700 2007-08-20

Comments (none posted)

kdebase: kdm passwordless login vulnerability

Package(s):	kdebase kdm	CVE #(s):	CVE-2007-4569
Created:	September 21, 2007	Updated:	November 13, 2007
Description:	According to this KDE advisory KDM can be tricked into performing a password-less login even for accounts with a password set under certain circumstances, namely autologin to be configured and "shutdown with password" enabled. KDE versions 3.3.0 up to including 3.5.7 are vulnerable.
Alerts:	Gentoo 200710-15 2007-10-14 Fedora FEDORA-2007-716 2007-10-08 Fedora FEDORA-2007-2361 2007-10-03 Mandriva MDKSA-2007:190 2007-09-27 Ubuntu USN-517-1 2007-09-24 Slackware SSA:2007-264-01 2007-09-24 rPath rPSA-2007-0194-1 2007-09-20 Debian DSA-1376 2007-09-21

Comments (none posted)

kdelibs: kate backup file permission leak

Package(s):	kdelibs kate kwrite	CVE #(s):	CAN-2005-1920
Created:	July 19, 2005	Updated:	September 21, 2010
Description:	Kate / Kwrite, as shipped with KDE 3.2.x up to including 3.4.0, creates a file backup before saving a modified file. These backup files are created with default permissions, even if the original file had more strict permissions set. See this advisory for more information.
Alerts:	Gentoo 200611-21 2006-11-27 Debian DSA-804-2 2005-11-10 Debian DSA-804-1 2005-09-08 Red Hat RHSA-2005:612-01 2005-07-27 Ubuntu USN-150-1 2005-07-21 Mandriva MDKSA-2005:122 2005-07-20 Fedora FEDORA-2005-594 2005-07-19

Comments (1 posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2007-1357
Created:	April 16, 2007	Updated:	November 14, 2007
Description:	The atalk_sum_skb function in AppleTalk for Linux kernel 2.6.x before 2.6.21, and possibly 2.4.x, allows remote attackers to cause a denial of service (crash) via an AppleTalk frame that is shorter than the specified length, which triggers a BUG_ON call when an attempt is made to perform a checksum.
Alerts:	SuSE SUSE-SA:2007:035 2007-06-14 Ubuntu USN-464-1 2007-05-23 SuSE SUSE-SA:2007:030 2007-05-10 SuSE SUSE-SA:2007:029 2007-05-03 rPath rPSA-2007-0071-1 2007-04-16 Fedora FEDORA-2007-432 2007-04-13 Fedora FEDORA-2007-433 2007-04-13

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2006-4623
Created:	October 18, 2006	Updated:	November 14, 2007
Description:	The kernel DVB layer can be caused to crash with maliciously-formatted unidirectional lightweight encapsulation (ULE) data.
Alerts:	Ubuntu USN-489-1 2007-07-19 rPath rPSA-2006-0194-1 2006-10-17

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2007-3642
Created:	July 23, 2007	Updated:	November 14, 2007
Description:	The decode_choice function in net/netfilter/bf_conntrack_h323_asn1.c in the Linux kernel before 2.6.22 allows remote attackers to cause a denial of service (crash) via an encoded, out-of-range index value for a choice field, which triggers a NULL pointer dereference.
Alerts:	Ubuntu USN-510-1 2007-08-31 Debian DSA-1356-1 2007-08-15 Fedora FEDORA-2007-655 2007-08-09 Fedora FEDORA-2007-1130 2007-07-20

Comments (none posted)

kernel: out-of-bounds access

Package(s):	kernel	CVE #(s):	CVE-2007-4573
Created:	September 25, 2007	Updated:	December 6, 2010
Description:	The IA32 system call emulation functionality in Linux kernel 2.4.x and 2.6.x before 2.6.22.7, when running on the x86_64 architecture, does not zero extend the eax register after the 32bit entry path to ptrace is used, which might allow local users to gain privileges by triggering an out-of-bounds access to the system call table using the %RAX register.
Alerts:	Mandriva MDVSA-2010:247 2010-12-03 Mandriva MDVSA-2010:188 2010-09-23 Mandriva MDVSA-2010:198 2010-10-07 Mandriva MDVSA-2008:105 2007-05-21 Debian DSA-1504 2008-02-22 Mandriva MDVSA-2008:008 2008-01-11 SuSE SUSE-SA:2007:064 2007-12-04 SuSE SUSE-SA:2007:053 2007-10-12 Mandriva MDKSA-2007:195 2007-10-15 Mandriva MDKSA-2007:196 2007-10-15 Debian DSA-1381-2 2007-10-12 Debian DSA-1381-1 2007-10-02 Debian DSA-1378-2 2007-09-28 Debian DSA-1378-1 2007-09-27 Red Hat RHSA-2007:0938-01 2007-09-27 Red Hat RHSA-2007:0937-01 2007-09-27 Red Hat RHSA-2007:0936-01 2007-09-27 Ubuntu USN-518-1 2007-09-25 rPath rPSA-2007-0198-1 2007-09-24 Fedora FEDORA-2007-712 2007-09-24 Fedora FEDORA-2007-2298 2007-09-25

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2007-0005 CVE-2007-1000
Created:	March 15, 2007	Updated:	November 14, 2007
Description:	The Linux kernel has a boundary error problem with the Omnikey CardMan 4040 driver read and write functions. This can be used to cause a buffer overflow and possible execution or arbitrary code with kernel privileges. The ipv6_getsockopt_sticky function in net/ipv6/ipv6_sockglue.c is vulnerable to a NULL pointer dereference. Local users can use this to crash the kernel or to disclose kernel memory.
Alerts:	Fedora FEDORA-2007-599 2007-06-21 Ubuntu USN-489-1 2007-07-19 Ubuntu USN-486-1 2007-07-17 Debian DSA-1286-1 2007-05-02 Red Hat RHSA-2007:0169-01 2007-04-30 Mandriva MDKSA-2007:078 2007-04-04 Fedora FEDORA-2007-336 2007-03-14 Fedora FEDORA-2007-335 2007-03-14

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2006-0558 CVE-2007-1217
Created:	September 4, 2007	Updated:	November 14, 2007
Description:	A flaw in the ISDN CAPI subsystem could allow a remote user to cause a denial of service or potential remote access. Exploitation would require the attacker to be able to send arbitrary frames over the ISDN network to the victim's machine. A flaw in the perfmon subsystem on ia64 platforms could allow a local user to cause a denial of service.
Alerts:	Red Hat RHSA-2007:0671-01 2007-08-16 Red Hat RHSA-2007:0673-01 2007-08-08 Red Hat RHSA-2007:0672-01 2007-08-08 Red Hat RHSA-2007:0705-01 2007-09-13 Red Hat RHSA-2007:0774-01 2007-09-04

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2006-0007 CVE-2007-0006
Created:	February 15, 2007	Updated:	November 14, 2007
Description:	Linux kernel versions from 2.6.9 to 2.6.20 have a denial of service vulnerability. A remote attacker can cause the key_alloc_serial function's key serial number collision avoidance code to have a null dereference, resulting in a crash.
Alerts:	Fedora FEDORA-2007-599 2007-06-21 Red Hat RHSA-2007:0099-02 2007-03-14 rPath rPSA-2007-0050-1 2007-03-06 Red Hat RHSA-2007:0085-01 2007-02-27 Mandriva MDKSA-2007:047 2007-02-21 Fedora FEDORA-2007-226 2007-02-13 Fedora FEDORA-2007-225 2007-02-13

Comments (1 posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2006-4535 CVE-2006-4538
Created:	September 18, 2006	Updated:	January 5, 2009
Description:	Sridhar Samudrala discovered a local denial of service vulnerability in the handling of SCTP sockets. By opening such a socket with a special SO_LINGER value, a local attacker could exploit this to crash the kernel. (CVE-2006-4535) Kirill Korotaev discovered that the ELF loader on the ia64 and sparc platforms did not sufficiently verify the memory layout. By attempting to execute a specially crafted executable, a local user could exploit this to crash the kernel. (CVE-2006-4538)
Alerts:	Red Hat RHSA-2008:0787-01 2009-01-05 Red Hat RHSA-2007:1049-01 2007-12-03 Mandriva MDKSA-2006:182 2006-10-11 Red Hat RHSA-2006:0689-01 2006-10-05 Debian DSA-1184-2 2006-09-26 Debian DSA-1184-1 2006-09-25 Debian DSA-1183-1 2006-09-25 Ubuntu USN-347-1 2006-09-18

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2007-1861 CVE-2007-2242
Created:	May 1, 2007	Updated:	February 8, 2008
Description:	The netlink protocol has an infinite recursion bug that allows users to cause a kernel crash. Also the IPv6 protocol allows remote attackers to cause a denial of service via crafted IPv6 type 0 route headers (IPV6_RTHDR_TYPE_0) that create network amplification between two routers.
Alerts:	SuSE SUSE-SA:2008:006 2008-02-07 Ubuntu USN-508-1 2007-08-31 Mandriva MDKSA-2007:171 2007-08-28 Ubuntu USN-489-1 2007-07-19 Ubuntu USN-486-1 2007-07-17 SuSE SUSE-SA:2007:051 2007-09-06 Mandriva MDKSA-2007:216 2007-11-13 Red Hat RHSA-2007:0347-01 2007-05-16 Debian DSA-1289-1 2007-05-13 Foresight FLEA-2007-0016-1 2007-05-08 rPath rPSA-2007-0084-1 2007-05-01 Fedora FEDORA-2007-483 2007-05-01 Fedora FEDORA-2007-482 2007-05-01

Comments (none posted)

kernel: denial of service by memory consumption

Package(s):	kernel	CVE #(s):	CVE-2006-2936
Created:	July 17, 2006	Updated:	November 14, 2007
Description:	The ftdi_sio driver (usb/serial/ftdi_sio.c) in Linux kernel 2.6.x up to 2.6.17, and possibly later versions, allows local users to cause a denial of service (memory consumption) by writing more data to the serial port than the driver can handle, which causes the data to be queued.
Alerts:	SuSE SUSE-SA:2007:035 2007-06-14 Mandriva MDKSA-2006:151 2006-08-25 Mandriva MDKSA-2006:150 2006-08-25 Ubuntu USN-331-1 2006-08-03 rPath rPSA-2006-0130-1 2006-07-17

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2007-0772
Created:	February 23, 2007	Updated:	November 14, 2007
Description:	The Linux kernel before 2.6.20.1 allows remote attackers to cause a denial of service (oops) via a crafted NFSACL 2 ACCESS request that triggers a free of an incorrect pointer.
Alerts:	Fedora FEDORA-2007-599 2007-06-21 Ubuntu USN-451-1 2007-04-10 SuSE SUSE-SA:2007:021 2007-03-16 Mandriva MDKSA-2007:060 2006-03-09 Fedora FEDORA-2007-291 2007-03-02 Fedora FEDORA-2007-277 2007-03-02 SuSE SUSE-SA:2007:018 2007-02-27 rPath rPSA-2007-0036-1 2007-02-23

Comments (none posted)

kernel: several vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2007-1353 CVE-2007-2451 CVE-2007-2453
Created:	June 11, 2007	Updated:	March 6, 2008
Description:	Ilja van Sprundel discovered that Bluetooth setsockopt calls could leak kernel memory contents via an uninitialized stack buffer. A local attacker could exploit this flaw to view sensitive kernel information. (CVE-2007-1353) The GEODE-AES driver did not correctly initialize its encryption key. Any data encrypted using this type of device would be easily compromised. (CVE-2007-2451) The random number generator was hashing a subset of the available entropy, leading to slightly less random numbers. Additionally, systems without an entropy source would be seeded with the same inputs at boot time, leading to a repeatable series of random numbers. (CVE-2007-2453)
Alerts:	Debian DSA-1504 2008-02-22 Debian DSA-1503-2 2008-03-06 Debian DSA-1503 2008-02-22 Red Hat RHSA-2007:0488-01 2007-06-25 Debian DSA-1356-1 2007-08-15 SuSE SUSE-SA:2007:051 2007-09-06 Mandriva MDKSA-2007:216 2007-11-13 Mandriva MDKSA-2007:171 2007-08-28 Red Hat RHSA-2007:0671-01 2007-08-16 Red Hat RHSA-2007:0673-01 2007-08-08 Red Hat RHSA-2007:0672-01 2007-08-08 Ubuntu USN-489-1 2007-07-19 Ubuntu USN-486-1 2007-07-17 Fedora FEDORA-2007-600 2007-06-25 Fedora FEDORA-2007-599 2007-06-21 SuSE SUSE-SA:2007:035 2007-06-14 Red Hat RHSA-2007:0376-01 2007-06-14 Fedora FEDORA-2007-0409 2007-06-13 Ubuntu USN-470-1 2007-06-08

Comments (none posted)

kernel: signal handling flaw on PPC

Package(s):	kernel	CVE #(s):	CVE-2007-3107
Created:	July 10, 2007	Updated:	February 4, 2008
Description:	A flaw in the signal handling on PowerPC-based systems that allowed a local user to cause a denial of service (floating point corruption).
Alerts:	Ubuntu USN-574-1 2008-02-04 SuSE SUSE-SA:2007:053 2007-10-12 SuSE SUSE-SA:2007:051 2007-09-06 Red Hat RHSA-2007:0595-01 2007-07-10

Comments (none posted)

kernel: several vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2006-5823 CVE-2006-6054 CVE-2007-1592
Created:	June 12, 2007	Updated:	March 21, 2011
Description:	A flaw in the cramfs file system allows invalid compressed data to cause memory corruption (CVE-2006-5823) A flaw in the ext2 file system allows an invalid inode size to cause a denial of service (system hang) (CVE-2006-6054) A flaw in IPV6 flow label handling allows a local user to cause a denial of service (crash) (CVE-2007-1592)
Alerts:	Mandriva MDVSA-2011:051 2011-03-18 Debian DSA-1503-2 2008-03-06 Debian DSA-1504 2008-02-22 Debian DSA-1503 2008-02-22 Red Hat RHSA-2007:0673-01 2007-08-08 Red Hat RHSA-2007:0672-01 2007-08-08 SuSE SUSE-SA:2007:035 2007-06-14 Red Hat RHSA-2007:0347-01 2007-05-16 SuSE SUSE-SA:2007:043 2007-07-09 Debian DSA-1304-1 2007-06-16 rPath rPSA-2007-0124-1 2007-06-14 Red Hat RHSA-2007:0436-01 2007-06-11

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2006-5757
Created:	November 13, 2006	Updated:	November 14, 2007
Description:	From the MOKB-05-11-2006 advisory: "The ISO9660 filesystem handling code of the Linux 2.6.x kernel fails to properly handle corrupted data structures, leading to an exploitable denial of service condition. This particular vulnerability seems to be caused by a race condition and a signedness issue. When performing a read operation on a corrupted ISO9660 fs stream, the isofs_get_blocks() function will enter an infinite loop when __find_get_block_slow() callback from sb_getblk() fails ("due to various races between file io on the block device and getblk")."
Alerts:	Fedora FEDORA-2007-599 2007-06-21 Fedora FEDORA-2006-1223 2006-11-12 Fedora FEDORA-2006-1221 2006-11-10

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2006-2935 CVE-2006-4145 CVE-2006-3745
Created:	September 1, 2006	Updated:	July 30, 2008
Description:	Previous versions of the kernel package are subject to several vulnerabilities. Certain malformed UDF filesystems can cause the system to crash (denial of service). Malformed CDROM firmware or USB storage devices (such as USB keys) could cause system crash (denial of service), and if they were intentionally malformed, can cause arbitrary code to run with elevated privileges. In addition, the SCTP protocol is subject to a remote system crash (denial of service) attack.
Alerts:	Red Hat RHSA-2008:0665-01 2008-07-24 SuSE SUSE-SA:2007:053 2007-10-12 SuSE SUSE-SA:2006:064 2006-11-10 Red Hat RHSA-2006:0710-01 2006-10-19 SuSE SUSE-SA:2006:057 2006-09-28 Trustix TSLSA-2006-0051 2006-09-15 Ubuntu USN-346-2 2006-09-14 Ubuntu USN-346-1 2006-09-14 rPath rPSA-2006-0162-1 2006-08-31

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2006-5749 CVE-2006-4814 CVE-2006-6106
Created:	January 5, 2007	Updated:	January 8, 2009
Description:	A security issue has been reported in Linux kernel due to an error in drivers/isdn/i4l/isdn_ppp.c as the "isdn_ppp_ccp_reset_alloc_state()" function never initializes an event timer before scheduling it with the "add_timer()" function. The mincore function in the kernel does not properly lock access to user space, which has unspecified impact and attack vectors, possibly related to a deadlock. Another vulnerability has been reported in Linux kernel caused by a boundary error within the handling of incoming CAPI messages in net/bluetooth/cmtp/capi.c. This can be exploited to overwrite certain Kernel data structures.
Alerts:	Red Hat RHSA-2008:0787-01 2009-01-05 Red Hat RHSA-2009:0001-01 2009-01-08 CentOS CESA-2008:0211 2008-05-07 Red Hat RHSA-2008:0211-01 2008-05-07 Debian DSA-1503 2008-02-22 Debian DSA-1503-2 2008-03-06 SuSE SUSE-SA:2007:035 2007-06-14 SuSE SUSE-SA:2007:053 2007-10-12 Ubuntu USN-416-2 2007-03-01 Ubuntu USN-416-1 2007-02-01 rPath rPSA-2007-0031-1 2007-02-09 Mandriva MDKSA-2007:040 2007-02-07 Red Hat RHSA-2007:0014-01 2007-01-30 Mandriva MDKSA-2007:025 2007-01-23 Fedora FEDORA-2007-058 2007-01-18 Mandriva MDKSA-2007:012 2006-01-12 Trustix TSLSA-2007-0002 2007-01-05

Comments (none posted)

kernel: several vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2007-3851 CVE-2007-3848 CVE-2007-3105
Created:	August 17, 2007	Updated:	January 8, 2009
Description:	The drm/i915 component in the Linux kernel before 2.6.22.2, when used with i965G and later chipsets, allows local users with access to an X11 session and Direct Rendering Manager (DRM) to write to arbitrary memory locations and gain privileges via a crafted batchbuffer. (CVE-2007-3851) Linux kernel 2.4.35 and other versions allows local users to send arbitrary signals to a child process that is running at higher privileges by causing a setuid-root parent process to die, which delivers an attacker-controlled parent process death signal (PR_SET_PDEATHSIG). (CVE-2007-3848) Stack-based buffer overflow in the random number generator (RNG) implementation in the Linux kernel before 2.6.22 might allow local root users to cause a denial of service or gain privileges by setting the default wakeup threshold to a value greater than the output pool size, which triggers writing random numbers to the stack by the pool transfer function involving "bound check ordering". NOTE: this issue might only cross privilege boundaries in environments that have granular assignment of privileges for root. (CVE-2007-3105)
Alerts:	Red Hat RHSA-2008:0787-01 2009-01-05 Red Hat RHSA-2009:0001-01 2009-01-08 Mandriva MDVSA-2008:105 2007-05-21 SuSE SUSE-SA:2008:017 2008-03-28 Debian DSA-1504 2008-02-22 Debian DSA-1503-2 2008-03-06 Debian DSA-1503 2008-02-22 SuSE SUSE-SA:2008:006 2008-02-07 Red Hat RHSA-2007:1049-01 2007-12-03 SuSE SUSE-SA:2007:053 2007-10-12 Debian DSA-1356-1 2007-08-15 Mandriva MDKSA-2007:216 2007-11-13 Red Hat RHSA-2007:0939-01 2007-11-01 Red Hat RHSA-2007:0940-01 2007-10-22 Red Hat RHSA-2007:0705-01 2007-09-13 SuSE SUSE-SA:2007:051 2007-09-06 Fedora FEDORA-2007-679 2007-09-04 Ubuntu USN-510-1 2007-08-31 Debian DSA-1363-1 2007-08-31 Ubuntu USN-508-1 2007-08-31 Ubuntu USN-509-1 2007-08-31 Fedora FEDORA-2007-1785 2007-08-23 rPath rPSA-2007-0164-1 2007-08-16

Comments (1 posted)

krb5: multiple vulnerabilities

Package(s):	krb5	CVE #(s):	CVE-2007-2442 CVE-2007-2443 CVE-2007-2798
Created:	June 27, 2007	Updated:	March 24, 2008
Description:	David Coffey discovered an uninitialized pointer free flaw in the RPC library used by kadmind. A remote unauthenticated attacker who could access kadmind could trigger the flaw causing kadmind to crash or possibly execute arbitrary code (CVE-2007-2442). David Coffey also discovered an overflow flaw in the same RPC library. A remote unauthenticated attacker who could access kadmind could trigger the flaw causing kadmind to crash or possibly execute arbitrary code (CVE-2007-2443). Finally, a stack buffer overflow vulnerability was found in kadmind that allowed an unauthenticated user able to access kadmind the ability to trigger the vulnerability and possibly execute arbitrary code (CVE-2007-2798).
Alerts:	Gentoo 200707-11 2007-07-25 SuSE SUSE-SA:2007:038 2007-07-03 Trustix TSLSA-2007-0021 2007-06-29 Fedora FEDORA-2007-0740 2007-06-27 Debian DSA-1323-1 2007-06-28 rPath rPSA-2007-0135-1 2007-06-27 Foresight FLEA-2007-0029-1 2007-06-27 Fedora FEDORA-2007-621 2007-06-28 Fedora FEDORA-2007-620 2007-06-28 Ubuntu USN-477-1 2007-06-26 Red Hat RHSA-2007:0562-01 2007-06-26 Red Hat RHSA-2007:0384-01 2007-06-26 Mandriva MDKSA-2007:137 2007-06-26

Comments (none posted)

krb5: uninitialized pointers

Package(s):	krb5	CVE #(s):	CVE-2006-6143 CVE-2006-3084
Created:	January 10, 2007	Updated:	July 7, 2010
Description:	The kdamind daemon can, in some situations, perform operations on uninitialized pointers. This bug could conceivably open up the system to a code execution attack by an unauthenticated remote attacker, but it appears to be difficult to exploit. See this advisory for details.
Alerts:	Mandriva MDVSA-2010:129 2010-07-07 Gentoo 200701-21 2007-01-24 Ubuntu USN-408-1 2007-01-15 rPath rPSA-2007-0006-1 2007-01-11 Mandriva MDKSA-2007:008 2006-01-10 SuSE SUSE-SA:2007:004 2007-01-10 OpenPKG OpenPKG-SA-2007.006 2007-01-10 Fedora FEDORA-2007-033 2007-01-09 Fedora FEDORA-2007-034 2007-01-09

Comments (1 posted)

krb5: local privilege escalation

Package(s):	krb5	CVE #(s):	CVE-2006-3083
Created:	August 9, 2006	Updated:	July 7, 2010
Description:	Some kerberos applications fail to check the results of setuid() calls, with the result that, if that call fails, they could continue to execute as root after thinking they had switched to a nonprivileged user. A local attacker who can cause these calls to fail (through resource exhaustion, presumably) could exploit this bug to gain root privileges.
Alerts:	Mandriva MDVSA-2010:129 2010-07-07 SuSE SUSE-SR:2006:022 2006-09-08 Gentoo 200608-21 2006-08-23 Ubuntu USN-334-1 2006-08-16 Fedora FEDORA-2006-905 2006-08-09 Mandriva MDKSA-2006:139 2006-09-09 Gentoo 200608-15 2006-08-10 rPath rPSA-2006-0150-1 2006-08-09 Red Hat RHSA-2006:0612-01 2006-08-08 Debian DSA-1146-1 2006-08-09

Comments (none posted)

krb5: buffer overflow, uninitialized pointer

Package(s):	krb5	CVE #(s):	CVE-2007-3999 CVE-2007-4000
Created:	September 4, 2007	Updated:	March 24, 2008
Description:	Tenable Network Security discovered a stack buffer overflow flaw in the RPC library used by kadmind. A remote unauthenticated attacker who can access kadmind could trigger this flaw and cause kadmind to crash. Garrett Wollman discovered an uninitialized pointer flaw in kadmind. A remote unauthenticated attacker who can access kadmind could trigger this flaw and cause kadmind to crash.
Alerts:	Fedora FEDORA-2008-1017 2008-03-06 SuSE SUSE-SR:2007:024 2007-11-22 Debian DSA-1387 2007-10-15 Gentoo 200710-01 2007-10-04 Red Hat RHSA-2007:0951-01 2007-10-02 Red Hat RHSA-2007:0913-01 2007-09-19 Trustix TSLSA-2007-0026 2007-09-17 Mandriva MDKSA-2007:181 2007-09-12 Gentoo 200709-01 2007-09-11 Ubuntu USN-511-2 2007-09-07 Mandriva MDKSA-2007:174-1 2007-09-07 Fedora FEDORA-2007-694 2007-09-07 Fedora FEDORA-2007-2066 2007-09-07 Debian DSA-1367-2 2007-09-06 Foresight FLEA-2007-0050-1 2007-09-06 Mandriva MDKSA-2007:174 2007-09-06 Red Hat RHSA-2007:0892-01 2007-09-07 rPath rPSA-2007-0179-1 2007-09-06 Ubuntu USN-511-1 2007-09-04 Fedora FEDORA-2007-2017 2007-09-04 Fedora FEDORA-2007-690 2007-09-04 Debian DSA-1368-1 2007-09-04 Debian DSA-1367-1 2007-09-04 Red Hat RHSA-2007:0858-01 2007-09-04

Comments (none posted)

krb5: multiple vulnerabilities

Package(s):	krb5	CVE #(s):	CVE-2007-0956 CVE-2007-0957 CVE-2007-1216
Created:	April 3, 2007	Updated:	March 24, 2008
Description:	A flaw was found in the username handling of the MIT krb5 telnet daemon (telnetd). A remote attacker who can access the telnet port of a target machine could log in as root without requiring a password. MIT krb5 Security Advisory 2007-001 Buffer overflows were found which affect the Kerberos KDC and the kadmin server daemon. A remote attacker who can access the KDC could exploit this bug to run arbitrary code with the privileges of the KDC or kadmin server processes. MIT krb5 Security Advisory 2007-002 A double-free flaw was found in the GSSAPI library used by the kadmin server daemon. MIT krb5 Security Advisory 2007-003
Alerts:	Mandriva MDKSA-2007:077-1 2007-04-10 Foresight FLEA-2007-0008-1 2007-04-05 SuSE SUSE-SA:2007:025 2007-04-05 Mandriva MDKSA-2007:077 2006-04-04 rPath rPSA-2007-0063-1 2007-04-04 Ubuntu USN-449-1 2007-04-04 Gentoo 200704-02 2007-04-03 Fedora FEDORA-2007-409 2007-04-03 Fedora FEDORA-2007-408 2007-04-03 Debian DSA-1276-1 2007-04-03 Red Hat RHSA-2007:0095-01 2007-04-03

Comments (none posted)

ktorrent: incorrect validation

Package(s):	ktorrent	CVE #(s):	CVE-2007-1384 CVE-2007-1385 CVE-2007-1799
Created:	March 13, 2007	Updated:	October 24, 2007
Description:	Bryan Burns of Juniper Networks discovered that KTorrent did not correctly validate the destination file paths nor the HAVE statements sent by torrent peers. A malicious remote peer could send specially crafted messages to overwrite files or execute arbitrary code with user privileges.
Alerts:	Debian DSA-1373-2 2007-10-23 Debian DSA-1373-1 2007-09-11 Ubuntu USN-436-2 2007-05-18 Mandriva MDKSA-2007:095 2007-05-01 Gentoo 200705-01 2007-05-01 Slackware SSA:2007-093-02 2007-04-04 Ubuntu USN-436-1 2007-03-12

Comments (1 posted)

kvirc: remote arbitrary code execution

Package(s):	kvirc	CVE #(s):	CVE-2007-2951
Created:	September 14, 2007	Updated:	February 27, 2008
Description:	Stefan Cornelius from Secunia Research discovered that the "parseIrcUrl()" function in file src/kvirc/kernel/kvi_ircurl.cpp does not properly sanitize parts of the URI when building the command for KVIrc's internal script system.
Alerts:	SuSE SUSE-SR:2007:015 2007-08-03 Gentoo 200709-02 2007-09-13

Comments (none posted)

lftp: shell command execution

Package(s):	lftp	CVE #(s):	CVE-2007-2348
Created:	May 4, 2007	Updated:	September 16, 2009
Description:	mirror --script in lftp before 3.5.9 does not properly quote shell metacharacters, which might allow remote user-assisted attackers to execute shell commands via a malicious script. NOTE: it is not clear whether this issue crosses security boundaries, since the script already supports commands such as "get" which could overwrite executable files.
Alerts:	CentOS CESA-2009:1278 2009-09-15 Red Hat RHSA-2009:1278-02 2009-09-02 rPath rPSA-2007-0085-1 2007-05-03

Comments (none posted)

libarchive: pax extension header vulnerabilities

Package(s):	libarchive	CVE #(s):	CVE-2007-3641 CVE-2007-3644 CVE-2007-3645
Created:	August 9, 2007	Updated:	February 27, 2008
Description:	libarchive, a library for manipulating different streaming archive formats, has a number of pax extension header vulnerabilities. These may be used to cause a denial of service or for the execution of arbitrary code.
Alerts:	SuSE SUSE-SR:2007:015 2007-08-03 Debian DSA-1455-1 2008-01-08 Gentoo 200708-03 2007-08-08

Comments (none posted)

libexif: integer overflow

Package(s):	libexif	CVE #(s):	CVE-2007-2645
Created:	June 1, 2007	Updated:	February 11, 2008
Description:	Integer overflow in the exif_data_load_data_entry function in exif-data.c in libexif before 0.6.14 allows user-assisted remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via crafted EXIF data, involving the (1) doff or (2) s variable.
Alerts:	Debian DSA-1487-1 2008-02-08 Slackware SSA:2007-164-01 2007-06-14 Fedora FEDORA-2007-0414 2007-06-13 Fedora FEDORA-2007-548 2007-06-11 Ubuntu USN-471-1 2007-06-11 Mandriva MDKSA-2007:118 2007-06-08 Gentoo 200706-01 2007-06-05 rPath rPSA-2007-0115-1 2007-06-04 Foresight FLEA-2007-0024-1 2007-06-04 Fedora FEDORA-2007-0001 2007-06-01

Comments (none posted)

libmodplug: boundary errors

Package(s):	libmodplug	CVE #(s):	CVE-2006-4192
Created:	December 11, 2006	Updated:	May 4, 2011
Description:	Luigi Auriemma has reported various boundary errors in load_it.cpp and a boundary error in the "CSoundFile::ReadSample()" function in sndfile.cpp. A remote attacker can entice a user to read crafted modules or ITP files, which may trigger a buffer overflow resulting in the execution of arbitrary code with the privileges of the user running the application.
Alerts:	CentOS CESA-2011:0477 2011-05-04 Red Hat RHSA-2011:0477-01 2011-05-02 Ubuntu USN-521-1 2007-09-27 Mandriva MDKSA-2007:001 2007-01-02 Gentoo 200612-04 2006-12-10

Comments (none posted)

libphp-phpmailer: command execution

Package(s):	libphp-phpmailer	CVE #(s):	CVE-2007-3215
Created:	June 20, 2007	Updated:	June 25, 2009
Description:	libphp-phpmailer does not do sufficient input validation, enabling shell command injection attacks.
Alerts:	Ubuntu USN-791-1 2009-06-24 Debian DSA-1315-1 2007-06-19

Comments (none posted)

libpng: denial of service

Package(s):	libpng	CVE #(s):	CVE-2007-2445
Created:	May 17, 2007	Updated:	March 23, 2009
Description:	Libpng can be crashed when processing malformed PNG files. It may also be possible to exploit this vulnerability to execute arbitrary code.
Alerts:	Debian DSA-1750-1 2009-03-22 Debian DSA-1613-1 2008-07-22 Fedora FEDORA-2008-3979 2008-05-28 Ubuntu USN-472-1 2007-06-11 Mandriva MDKSA-2007:116 2007-06-05 Gentoo 200705-24 2007-05-31 Fedora FEDORA-2007-0001 2007-06-01 Fedora FEDORA-2007-529 2007-05-24 Fedora FEDORA-2007-528 2007-05-24 Red Hat RHSA-2007:0356-01 2007-05-17 OpenPKG OpenPKG-SA-2007.013 2007-05-18 Foresight FLEA-2007-0018-1 2007-05-17 Slackware SSA:2007-136-01 2007-05-17 rPath rPSA-2007-0102-1 2007-05-16

Comments (none posted)

libpng: buffer overflow

Package(s):	libpng	CVE #(s):	CVE-2006-3334
Created:	July 19, 2006	Updated:	December 15, 2008
Description:	In pngrutil.c, the function png_decompress_chunk() allocates insufficient space for an error message, potentially overwriting stack data, leading to a buffer overflow.
Alerts:	Gentoo 200812-15 2008-12-14 Mandriva MDKSA-2006:213 2006-11-16 rPath rPSA-2006-0133-1 2006-07-19 Gentoo 200607-06 2006-07-19

Comments (none posted)

libpng: heap based buffer overflow

Package(s):	libpng	CVE #(s):	CVE-2006-0481
Created:	February 13, 2006	Updated:	December 15, 2008
Description:	A heap based buffer overflow bug was found in the way libpng strips alpha channels from a PNG image. An attacker could create a carefully crafted PNG image file in such a way that it could cause an application linked with libpng to crash or execute arbitrary code when the file is opened by a victim.
Alerts:	Gentoo 200812-15 2008-12-14 Red Hat RHSA-2006:0205-01 2006-02-13

Comments (1 posted)

libsndfile: heap-based buffer overflow

Package(s):	libsndfile	CVE #(s):	CVE-2007-4974
Created:	September 25, 2007	Updated:	January 9, 2008
Description:	Heap-based buffer overflow in libsndfile 1.0.17 and earlier might allow remote attackers to execute arbitrary code via a FLAC file with crafted PCM data containing a block with a size that exceeds the previous block size.
Alerts:	SuSE SUSE-SR:2008:001 2008-01-09 Debian DSA-1442-1 2007-12-29 Gentoo 200710-04 2007-10-07 Ubuntu USN-525-1 2007-10-04 Mandriva MDKSA-2007:191 2007-10-01 Fedora FEDORA-2007-2236 2007-09-24

Comments (none posted)

libtiff: buffer overflow

Package(s):	libtiff	CVE #(s):	CVE-2006-2193
Created:	June 15, 2006	Updated:	September 1, 2008
Description:	The t2p_write_pdf_string function in libtiff 3.8.2 and earlier is vulnerable to a buffer overflow. Attackers can use a TIFF file with UTF-8 characters in the DocumentName tag to overflow a buffer, causing a denial of service, and possibly the execution of arbitrary code.
Alerts:	CentOS CESA-2008:0848 2008-08-30 Red Hat RHSA-2008:0848-01 2008-08-28 Fedora FEDORA-2006-952 2006-09-05 SuSE SUSE-SA:2006:044 2006-08-01 Gentoo 200607-03 2006-07-09 SuSE SUSE-SR:2006:014 2006-06-20 Trustix TSLSA-2006-0036 2006-06-16 Mandriva MDKSA-2006:102 2006-06-14

Comments (none posted)

libvorbis: multiple memory corruption flaws

Package(s):	libvorbis	CVE #(s):	CVE-2007-3106 CVE-2007-4029
Created:	July 27, 2007	Updated:	January 22, 2008
Description:	This iSEC Partners security advisory has details on multiple memory corruption flaws in libvorbis.
Alerts:	Debian DSA-1471-1 2008-01-21 Gentoo 200710-03 2007-10-07 Red Hat RHSA-2007:0845-02 2007-09-19 Fedora FEDORA-2007-677 2007-08-30 Fedora FEDORA-2007-1765 2007-08-23 Mandriva MDKSA-2007:167-1 2007-08-20 Mandriva MDKSA-2007:167 2007-08-18 Ubuntu USN-498-1 2007-08-16 Foresight FLEA-2007-0035-1 2007-07-27 rPath rPSA-2007-0150-1 2007-07-27

Comments (none posted)

libxml2 - arbitrary code execution

Package(s):	libxml2	CVE #(s):	CAN-2004-0110
Created:	February 26, 2004	Updated:	August 19, 2009
Description:	Yuuichi Teranishi discovered a flaw in libxml2 versions prior to 2.6.6. When fetching a remote resource via FTP or HTTP, libxml2 uses special parsing routines. These routines can overflow a buffer if passed a very long URL. If an attacker is able to find an application using libxml2 that parses remote resources and allows them to influence the URL, then this flaw could be used to execute arbitrary code.
Alerts:	Fedora FEDORA-2009-8594 2009-08-15 Fedora FEDORA-2009-8582 2009-08-15 Fedora-Legacy FLSA:1324 2004-07-19 Conectiva CLA-2004:836 2004-03-31 Gentoo 200403-01 2004-03-06 Trustix TSLSA-2004-0010 2004-03-05 OpenPKG OpenPKG-SA-2004.003 2004-03-05 Netwosix NW-2004-0004 2004-03-04 Debian DSA-455-1 2004-03-03 Mandrake MDKSA-2004:018 2004-03-03 Red Hat RHSA-2004:091-02 2004-03-03 Whitebox WBSA-2004:090-01 2004-03-01 Red Hat RHSA-2004:090-01 2004-02-26 Fedora FEDORA-2004-087 2004-02-25 Red Hat RHSA-2004:091-01 2004-02-26

Comments (none posted)

libxml2: multiple buffer overflows

Package(s):	libxml2	CVE #(s):	CAN-2004-0989
Created:	October 28, 2004	Updated:	August 19, 2009
Description:	libxml2 prior to version 2.6.14 has multiple buffer overflow vulnerabilities, if a local user passes a specially crafted FTP URL, arbitrary code may be executed.
Alerts:	Fedora FEDORA-2009-8594 2009-08-15 Fedora FEDORA-2009-8582 2009-08-15 Ubuntu USN-89-1 2005-02-28 Red Hat RHSA-2004:650-01 2004-12-16 Conectiva CLA-2004:890 2004-11-18 Red Hat RHSA-2004:615-01 2004-11-12 Mandrake MDKSA-2004:127 2004-11-04 Debian DSA-582-1 2004-11-02 Gentoo 200411-05 2004-11-02 Trustix TSLSA-2004-0055 2004-10-29 OpenPKG OpenPKG-SA-2004.050 2004-10-31 Ubuntu USN-10-1 2004-10-28 Fedora FEDORA-2004-353 2004-10-28

Comments (none posted)

lighttpd: buffer overflow

Package(s):	lighttpd	CVE #(s):	CVE-2007-4727
Created:	September 12, 2007	Updated:	October 8, 2007
Description:	From the Fedora advisory: Lighttpd (1.4.17 and earlier) is prone to a header overflow when using the mod_fastcgi extension, this can lead to arbitrary code execution in the fastcgi application.
Alerts:	Debian DSA 1362-2 2007-10-07 Gentoo 200709-16 2007-09-27 Foresight FLEA-2007-0054-1 2007-09-17 rPath rPSA-2007-0183-1 2007-09-14 Fedora FEDORA-2007-2132 2007-09-12

Comments (none posted)

lighttpd: denial of service

Package(s):	lighttpd	CVE #(s):	CVE-2007-3946 CVE-2007-3947 CVE-2007-3948 CVE-2007-3949 CVE-2007-3950
Created:	July 19, 2007	Updated:	July 15, 2008
Description:	The lighttpd web server has multiple vulnerabilities involving a remote access-control setting circumvention that is performed by the sending of malformed requests. This can be used to crash the server and cause a denial of service.
Alerts:	Debian DSA-1609-1 2008-07-15 SuSE SUSE-SR:2007:015 2007-08-03 Debian DSA-1362 2007-08-29 Gentoo 200708-11 2007-08-16 Fedora FEDORA-2007-1299 2007-07-26 Foresight FLEA-2007-0034-1 2007-07-26 rPath rPSA-2007-0145-1 2007-07-19

Comments (none posted)

lookup-el: insecure temporary file

Package(s):	lookup-el	CVE #(s):	CVE-2007-0237
Created:	March 19, 2007	Updated:	December 10, 2007
Description:	Tatsuya Kinoshita discovered that Lookup, a search interface to electronic dictionaries on emacsen, creates a temporary file in an insecure fashion when the ndeb-binary feature is used, which allows a local attacker to craft a symlink attack to overwrite arbitrary files.
Alerts:	Gentoo 200712-07 2007-12-09 Debian DSA-1269-1 2007-03-18

Comments (none posted)

lynx: arbitrary command execution

Package(s):	lynx	CVE #(s):	CVE-2005-2929
Created:	November 14, 2005	Updated:	September 14, 2009
Description:	An arbitrary command execute bug was found in the lynx "lynxcgi:" URI handler. An attacker could create a web page redirecting to a malicious URL which could execute arbitrary code as the user running lynx.
Alerts:	Gentoo 200909-15 2009-09-12 Fedora-Legacy FLSA:152832 2005-12-17 OpenPKG OpenPKG-SA-2005.026 2005-12-03 Fedora FEDORA-2005-1079 2005-11-14 Fedora FEDORA-2005-1078 2005-11-14 Gentoo 200511-09 2005-11-13 Mandriva MDKSA-2005:211 2005-11-12 Red Hat RHSA-2005:839-01 2005-11-11

Comments (none posted)

mapserver: multiple cross-site scripting vulnerabilities

Package(s):	mapserver	CVE #(s):	CVE-2007-4542 CVE-2007-4629
Created:	September 5, 2007	Updated:	April 7, 2008
Description:	CVE-2007-4542: Multiple cross-site scripting (XSS) vulnerabilities in MapServer before 4.10.3 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors involving the (1) processLine function in maptemplate.c and the (2) writeError function in mapserv.c in the mapserv CGI program. CVE-2007-4629: Buffer overflow in the processLine function in maptemplate.c in MapServer before 4.10.3 allows attackers to cause a denial of service and possibly execute arbitrary code via a mapfile with a long layer name, group name, or metadata entry name.
Alerts:	Debian DSA-1539-1 2008-04-04 Fedora FEDORA-2007-2018 2007-09-04

Comments (none posted)

mod_jk: proxy bypass

Package(s):	mod_jk	CVE #(s):	CVE-2007-1860
Created:	May 30, 2007	Updated:	March 7, 2008
Description:	From the Red Hat advisory: "Versions of mod_jk before 1.2.23 decoded request URLs by default inside Apache httpd and forwarded the encoded URL to Tomcat, which itself did a second decoding. If Tomcat was used behind mod_jk and configured to only proxy some contexts, an attacker could construct a carefully crafted HTTP request to work around the context restriction and potentially access non-proxied content."
Alerts:	SuSE SUSE-SR:2008:005 2008-03-06 Gentoo 200708-15 2007-08-19 Debian DSA-1312-1 2007-06-18 Red Hat RHSA-2007:0380-01 2007-05-30 Red Hat RHSA-2007:0379-01 2007-05-30

Comments (none posted)

moin: arbitrary JavaScript execution

Package(s):	moin	CVE #(s):	CVE-2007-2423
Created:	May 8, 2007	Updated:	March 10, 2008
Description:	A flaw was discovered in MoinMoin's error reporting when using the AttachFile action. By tricking a user into viewing a crafted MoinMoin URL, an attacker could execute arbitrary JavaScript as the current MoinMoin user, possibly exposing the user's authentication information for the domain where MoinMoin was hosted.
Alerts:	Debian DSA-1514-1 2008-03-09 Ubuntu USN-458-1 2007-05-07

Comments (none posted)

moodle: cross-site scripting

Package(s):	moodle	CVE #(s):	CVE-2007-3555
Created:	August 7, 2007	Updated:	December 22, 2008
Description:	A cross-site scripting (XSS) vulnerability in index.php in Moodle 1.7.1 allows remote attackers to inject arbitrary web script or HTML via a style expression in the search parameter.
Alerts:	Debian DSA-1691-1 2008-12-22 Fedora FEDORA-2008-0610 2008-01-15 Fedora FEDORA-2007-1445 2007-08-06

Comments (none posted)

mplayer: buffer overflow

Package(s):	mplayer	CVE #(s):	CVE-2007-1246
Created:	March 8, 2007	Updated:	April 1, 2008
Description:	MPlayer versions up to 1.0rc1 have a buffer overflow in the loader/dmo/DMO_VideoDecoder.c DMO_VideoDecoder_Open function. user-assisted remote attackers can use this to create a buffer overflow and possibly execute arbitrary code.
Alerts:	Debian DSA-1536-1 2008-03-31 Gentoo 200705-21 2007-05-30 Foresight FLEA-2007-0013-1 2007-04-23 Slackware SSA:2007-109-02 2007-04-20 Gentoo 200704-09 2007-04-14 Ubuntu USN-433-1 2007-03-09 Mandriva MDKSA-2007:057 2007-03-08 Mandriva MDKSA-2007:055 2007-03-08

Comments (none posted)

mydns: buffer overflows

Package(s):	mydns	CVE #(s):	CVE-2007-2362
Created:	May 23, 2007	Updated:	December 17, 2007
Description:	Multiple buffer overflows in MyDNS allow remote attackers to cause a denial of service (daemon crash) and possibly execution of arbitrary code.
Alerts:	Debian DSA-1434-1 2007-12-16 Debian-Testing DTSA-36-1 2007-05-22

Comments (none posted)

mysql: denial of service

Package(s):	mysql	CVE #(s):	CVE-2007-1420
Created:	March 22, 2007	Updated:	May 21, 2008
Description:	MySQL subselect queries using "ORDER BY" can be used by an attacker with access to a MySQL instance in order to create an intermittent denial of service.
Alerts:	Red Hat RHSA-2008:0364-01 2008-05-21 Mandriva MDKSA-2007:139 2007-07-04 rPath rPSA-2007-0107-1 2007-05-23 Gentoo 200705-11 2007-05-08 Ubuntu USN-440-1 2007-03-21

Comments (none posted)

mysql: format string bug

Package(s):	mysql	CVE #(s):	CVE-2006-3469
Created:	July 21, 2006	Updated:	July 30, 2008
Description:	Jean-David Maillefer discovered a format string bug in the date_format() function's error reporting. By calling the function with invalid arguments, an authenticated user could exploit this to crash the server.
Alerts:	Red Hat RHSA-2008:0768-01 2008-07-24 Slackware SSA:2006-211-01 2006-07-31 Ubuntu USN-321-1 2006-07-21

Comments (none posted)

MySQL: privilege violations

Package(s):	mysql	CVE #(s):	CVE-2006-4031 CVE-2006-4226
Created:	August 25, 2006	Updated:	July 30, 2008
Description:	MySQL 4.1 before 4.1.21 and 5.0 before 5.0.24 allows a local user to access a table through a previously created MERGE table, even after the user's privileges are revoked for the original table, which might violate intended security policy (CVE-2006-4031). MySQL 4.1 before 4.1.21, 5.0 before 5.0.25, and 5.1 before 5.1.12, when run on case-sensitive filesystems, allows remote authenticated users to create or access a database when the database name differs only in case from a database for which they have permissions (CVE-2006-4226).
Alerts:	Red Hat RHSA-2008:0768-01 2008-07-24 Red Hat RHSA-2008:0364-01 2008-05-21 Red Hat RHSA-2007:0152-01 2007-04-03 Red Hat RHSA-2007:0083-01 2007-02-19 Fedora FEDORA-2006-1298 2006-11-27 Fedora FEDORA-2006-1297 2006-11-27 Ubuntu USN-338-1 2006-09-05 Mandriva MDKSA-2006:149 2006-08-24

Comments (none posted)

mysql: multiple vulnerabilities

Package(s):	mysql	CVE #(s):	CVE-2007-3780
Created:	July 17, 2007	Updated:	November 27, 2007
Description:	MySQL Community Server before v5.0.45 has multiple vulnerabilities. See the MySQL Community Server 5.0.45 release announcement for details.
Alerts:	Debian DSA-1413-1 2007-11-26 Ubuntu USN-528-1 2007-10-11 Red Hat RHSA-2007:0894-01 2007-09-10 Mandriva MDKSA-2007:177 2007-09-06 Red Hat RHSA-2007:0875-01 2007-08-30 Gentoo 200708-10 2007-08-16 rPath rPSA-2007-0143-1 2007-07-17

Comments (none posted)

MySQL: logging bypass

Package(s):	mysql	CVE #(s):	CVE-2006-0903
Created:	April 4, 2006	Updated:	May 21, 2008
Description:	MySQL 5.0.18 and earlier allows local users to bypass logging mechanisms via SQL queries that contain the NULL character, which are not properly handled by the mysql_real_query function. NOTE: this issue was originally reported for the mysql_query function, but the vendor states that since mysql_query expects a null character, this is not an issue for mysql_query.
Alerts:	Red Hat RHSA-2008:0364-01 2008-05-21 Ubuntu USN-274-2 2006-05-15 Ubuntu USN-274-1 2006-04-27 Mandriva MDKSA-2006:064 2006-04-03

Comments (2 posted)

nbd: arbitrary code execution

Package(s):	nbd	CVE #(s):	CVE-2005-3534
Created:	January 6, 2006	Updated:	March 7, 2011
Description:	Kurt Fitzner discovered that the NBD (network block device) server did not correctly verify the maximum size of request packets. By sending specially crafted large request packets, a remote attacker who is allowed to access the server could exploit this to execute arbitrary code with root privileges.
Alerts:	SuSE SUSE-SR:2006:001 2006-01-13 Ubuntu USN-237-1 2006-01-06

Comments (none posted)

nginx: cross site scripting

Package(s):	nginx	CVE #(s):
Created:	July 20, 2007	Updated:	September 14, 2009
Description:	Nginx [engine x] is an HTTP(S) server, HTTP(S) reverse proxy and IMAP/POP3 proxy server written by Igor Sysoev. The "msie_refresh" directive could allow cross site scripting.
Alerts:	Fedora FEDORA-2007-1158 2007-07-19

Comments (none posted)

OpenOffice.org: arbitrary code execution

Package(s):	openoffice.org	CVE #(s):	CVE-2007-0245
Created:	June 13, 2007	Updated:	June 12, 2008
Description:	A specially crafted RTF file could cause the filter to overwrite data on the heap, which may lead to the execution of arbitrary code.
Alerts:	Fedora FEDORA-2008-5239 2008-06-11 Fedora FEDORA-2008-4104 2008-05-17 rPath rPSA-2007-0160-1 2007-08-14 Ubuntu USN-482-1 2007-07-10 Mandriva MDKSA-2007:144 2007-07-10 Gentoo 200707-02 2007-07-02 SuSE SUSE-SA:2007:037 2007-06-28 Fedora FEDORA-2007-606 2007-06-25 Fedora FEDORA-2007-0410 2007-06-13 Fedora FEDORA-2007-572 2007-06-12 Red Hat RHSA-2007:0406-01 2007-06-13 Debian DSA-1307-1 2007-06-12

Comments (none posted)

openoffice.org: arbitrary code execution via TIFF images

Package(s):	openoffice.org	CVE #(s):	CVE-2007-2834
Created:	September 17, 2007	Updated:	June 12, 2008
Description:	A heap overflow vulnerability has been discovered in the TIFF parsing code of the OpenOffice.org suite. The parser uses untrusted values from the TIFF file to calculate the number of bytes of memory to allocate. A specially crafted TIFF image could trigger an integer overflow and subsequently a buffer overflow that could cause the execution of arbitrary code.
Alerts:	Fedora FEDORA-2008-5239 2008-06-11 Fedora FEDORA-2008-4104 2008-05-17 Gentoo 200710-24 2007-10-23 Ubuntu USN-524-1 2007-10-04 Fedora FEDORA-2007-2372 2007-10-03 SuSE SUSE-SA:2007:052 2007-09-21 Mandriva MDKSA-2007:186 2007-09-17 rPath rPSA-2007-0189-1 2007-09-18 Foresight FLEA-2007-0056-1 2007-09-18 Fedora FEDORA-2007-700 2007-09-18 Red Hat RHSA-2007:0848-01 2007-09-18 Debian DSA-1375-1 2007-09-17

Comments (none posted)

OpenSSH: denial of service

Package(s):	openssh	CVE #(s):	CVE-2006-4925 CVE-2006-5052
Created:	October 6, 2006	Updated:	November 15, 2007
Description:	packet.c in ssh in OpenSSH allows remote attackers to cause a denial of service (crash) by sending an invalid protocol sequence with USERAUTH_SUCCESS before NEWKEYS, which causes newkeys[mode] to be NULL. An unspecified vulnerability in portable OpenSSH before 4.4, when running on some platforms, allows remote attackers to determine the validity of usernames via unknown vectors involving a GSSAPI "authentication abort."
Alerts:	Red Hat RHSA-2007:0703-02 2007-11-15 Red Hat RHSA-2007:0540-04 2007-11-07 Fedora FEDORA-2007-394 2007-04-03 Gentoo 200611-06 2006-11-13 SuSE SUSE-SA:2006:062 2006-10-20 rPath rPSA-2006-0185-1 2006-10-05

Comments (none posted)

openssh: remote denial of service

Package(s):	openssh	CVE #(s):	CVE-2006-4924 CVE-2006-5051
Created:	September 27, 2006	Updated:	September 17, 2008
Description:	Openssh 4.4 fixes some security issues, including a pre-authentication denial of service, an unsafe signal hander and on portable OpenSSH a GSSAPI authentication abort could be used to determine the validity of usernames on some platforms.
Alerts:	Debian DSA-1638-1 2008-09-16 Debian DSA-1212-1 2006-11-15 Fedora FEDORA-2006-1011 2006-10-03 Debian DSA-1189-1 2006-10-04 Mandriva MDKSA-2006:179 2006-10-03 Ubuntu USN-355-1 2006-10-02 OpenPKG OpenPKG-SA-2006.022 2006-10-01 Slackware SSA:2006-272-02 2006-09-29 Red Hat RHSA-2006:0698-01 2006-09-28 Red Hat RHSA-2006:0697-01 2006-09-28 Gentoo 200609-17:02 2006-09-27 rPath rPSA-2006-0174-1 2006-09-27 Gentoo 200609-17 2006-09-27

Comments (none posted)

openssl: private key attack

Package(s):	openssl	CVE #(s):	CVE-2007-3108
Created:	August 7, 2007	Updated:	May 13, 2008
Description:	OpenSSL could allow a local user in certain circumstances to divulge information about private keys being used.
Alerts:	Debian DSA-1571-1 2008-05-13 Red Hat RHSA-2007:1003-02 2007-11-15 Ubuntu USN-522-1 2007-09-29 rPath rPSA-2007-0199-1 2007-09-25 Fedora FEDORA-2007-661 2007-08-13 Foresight FLEA-2007-0043-1 2007-08-13 rPath rPSA-2007-0155-1 2007-08-10 Fedora FEDORA-2007-1444 2007-08-06

Comments (none posted)

opera: multiple vulnerabilities

Package(s):	opera	CVE #(s):	CVE-2007-4367 CVE-2007-3929 CVE-2007-3142 CVE-2007-3819
Created:	August 23, 2007	Updated:	February 27, 2008
Description:	The Opera browser has multiple vulnerabilities. The JavaScript engine is vulnerable to a virtual function call on an invalid pointer that can be triggered by specially crafted JavaScript. A freed pointer in the BitTorrent support may be accessed, this can be used for malicious code execution. The browser is vulnerable to several memory read protection errors. There are URI display errors that can be used to trick users into visiting arbitrary web sites.
Alerts:	SuSE SUSE-SR:2007:015 2007-08-03 SuSE SUSE-SA:2007:050 2007-08-30 Gentoo 200708-17 2007-08-22

Comments (none posted)

pam: privilege escalation

Package(s):	pam	CVE #(s):	CVE-2007-1716
Created:	June 12, 2007	Updated:	November 15, 2007
Description:	A flaw was found in the way pam_console set console device permissions. It was possible for various console devices to retain ownership of the console user after logging out, possibly leaking information to an unauthorized user.
Alerts:	Red Hat RHSA-2007:0737-02 2007-11-15 Red Hat RHSA-2007:0555-04 2007-11-07 Fedora FEDORA-2007-546 2007-06-11 Red Hat RHSA-2007:0465-01 2007-06-11

Comments (none posted)

perl-Net-DNS: predictable id sequence

Package(s):	perl-Net-DNS	CVE #(s):	CVE-2007-3377
Created:	June 26, 2007	Updated:	March 12, 2008
Description:	Net::DNS before 0.60 uses an id sequence that is predictable and the same in all child processes.
Alerts:	Debian DSA-1515-1 2008-03-11 SuSE SUSE-SR:2007:017 2007-08-17 Gentoo 200708-06 2007-08-11 rPath rPSA-2007-0142-1 2007-07-17 Ubuntu USN-483-1 2007-07-11 Mandriva MDKSA-2007:146 2007-07-12 Red Hat RHSA-2007:0675-01 2007-07-12 Red Hat RHSA-2007:0674-01 2007-07-12 Fedora FEDORA-2007-609 2007-07-02 Fedora FEDORA-2007-612 2007-07-02 Fedora FEDORA-2007-0668 2007-06-25

Comments (none posted)

php: multiple vulnerabilities

Package(s):	php	CVE #(s):	CVE-2007-1001 CVE-2007-1285 CVE-2007-1718 CVE-2007-1583
Created:	April 16, 2007	Updated:	December 4, 2007
Description:	A denial of service flaw was found in the way PHP processed a deeply nested array. A remote attacker could cause the PHP interpreter to crash by submitting an input variable with a deeply nested array. (CVE-2007-1285) A flaw was found in the way the mbstring extension set global variables. A script which used the mb_parse_str() function to set global variables could be forced to enable the register_globals configuration option, possibly resulting in global variable injection. (CVE-2007-1583) A flaw was discovered in the way PHP's mail() function processed header data. If a script sent mail using a Subject header containing a string from an untrusted source, a remote attacker could send bulk e-mail to unintended recipients. (CVE-2007-1718) A heap based buffer overflow flaw was discovered in PHP's gd extension. A script that could be forced to process WBMP images from an untrusted source could result in arbitrary code execution. (CVE-2007-1001)
Alerts:	Ubuntu USN-549-2 2007-12-03 Ubuntu USN-549-1 2007-11-29 OpenPKG OpenPKG-SA-2007.019 2007-05-28 Fedora FEDORA-2007-526 2007-05-24 SuSE SUSE-SA:2007:032 2007-05-23 Slackware SSA:2007-127-01 2007-05-08 Debian DSA-1283-1 2007-04-29 Ubuntu USN-455-1 2007-04-27 Debian DSA-1282-1 2007-04-26 Red Hat RHSA-2007:0153-01 2007-04-20 Mandriva MDKSA-2007:090 2007-04-18 Mandriva MDKSA-2007:089 2007-04-18 Mandriva MDKSA-2007:088 2007-04-18 Mandriva MDKSA-2007:087 2007-04-18 Fedora FEDORA-2007-455 2007-04-18 rPath rPSA-2007-0073-1 2007-04-18 Fedora FEDORA-2007-415 2007-04-17 Red Hat RHSA-2007:0155-01 2007-04-16 Red Hat RHSA-2007:0154-01 2007-04-16 Red Hat RHSA-2007:0162-01 2007-04-16

Comments (none posted)

php: several vulnerabilities

Package(s):	php	CVE #(s):	CVE-2006-4481 CVE-2006-4484 CVE-2006-4485
Created:	September 8, 2006	Updated:	June 13, 2008
Description:	The file_exists and imap_reopen functions in PHP before 5.1.5 do not check for the safe_mode and open_basedir settings, which allows local users to bypass the settings (CVE-2006-4481). A buffer overflow in the LWZReadByte function in ext/gd/libgd/gd_gif_in.c in the GD extension in PHP before 5.1.5 allows remote attackers to have an unknown impact via a GIF file with input_code_size greater than MAX_LWZ_BITS, which triggers an overflow when initializing the table array (CVE-2006-4484). The stripos function in PHP before 5.1.5 has unknown impact and attack vectors related to an out-of-bounds read (CVE-2006-4485).
Alerts:	SuSE SUSE-SR:2008:013 2008-06-13 Mandriva MDVSA-2008:077 2007-03-26 SuSE SUSE-SR:2008:005 2008-03-06 Red Hat RHSA-2008:0146-01 2008-02-28 Fedora FEDORA-2008-1643 2008-02-13 Foresight FLEA-2008-0007-1 2008-02-11 Fedora FEDORA-2008-1122 2008-02-05 Fedora FEDORA-2008-1131 2008-02-05 SuSE SUSE-SR:2008:003 2008-02-07 Mandriva MDVSA-2008:038 2007-02-07 rPath rPSA-2008-0046-1 2008-02-06 Gentoo 200802-01 2008-02-06 rPath rPSA-2006-0182-1 2006-10-05 SuSE SUSE-SA:2006:052 2006-09-21 Red Hat RHSA-2006:0669-01 2006-09-21 Mandriva MDKSA-2006:162 2006-09-07

Comments (1 posted)

php: multiple vulnerabilities

Package(s):	php	CVE #(s):	CVE-2007-2872 CVE-2007-2756
Created:	June 1, 2007	Updated:	January 29, 2008
Description:	According to a vendor release announcement multiple security enhancements and fixes were fixed in version 5.2.3 of the programming language PHP.
Alerts:	SuSE SUSE-SA:2008:004 2008-01-29 Ubuntu USN-549-2 2007-12-03 Red Hat RHSA-2007:0891-01 2007-10-25 Ubuntu USN-549-1 2007-11-29 Red Hat RHSA-2007:0888-01 2007-10-23 Gentoo 200710-02 2007-10-07 Red Hat RHSA-2007:0889-01 2007-09-26 Fedora FEDORA-2007-709 2007-09-24 Mandriva MDKSA-2007:187 2007-09-21 Red Hat RHSA-2007:0890-02 2007-09-20 Fedora FEDORA-2007-2215 2007-09-18 rPath rPSA-2007-0188-1 2007-09-17 Slackware SSA:2007-255-03 2007-09-13 rPath rPSA-2007-0117-1 2007-06-07 Slackware SSA:2007-152-01 2007-06-04 OpenPKG OpenPKG-SA-2007.020 2007-06-01

Comments (none posted)

php: buffer overflows

Package(s):	php	CVE #(s):	CVE-2006-5465
Created:	November 3, 2006	Updated:	January 18, 2010
Description:	The Hardened-PHP Project discovered buffer overflows in htmlentities/htmlspecialchars internal routines to the PHP Project. Of course the whole purpose of these functions is to be filled with user input. (The overflow can only be when UTF-8 is used)
Alerts:	Mandriva MDVSA-2010:007 2010-01-15 SuSE SUSE-SA:2006:067 2006-11-15 rPath rPSA-2006-0205-1 2006-11-09 Red Hat RHSA-2006:0731-01 2006-11-10 Red Hat RHSA-2006:0730-01 2006-11-06 Debian DSA-1206-1 2006-11-06 Fedora FEDORA-2006-1169 2006-11-06 Fedora FEDORA-2006-1168 2006-11-06 Slackware SSA:2006-307-01 2006-11-06 OpenPKG OpenPKG-SA-2006.028 2006-11-06 Ubuntu USN-375-1 2006-11-02 Mandriva MDKSA-2006:196 2006-11-02

Comments (none posted)

phpbb2: missing input sanitizing

Package(s):	phpbb2	CVE #(s):	CVE-2006-1896
Created:	May 22, 2006	Updated:	February 11, 2008
Description:	It was discovered that phpbb2, a web based bulletin board, insufficiently sanitizes values passed to the "Font Color 3" setting, which might lead to the execution of injected code by admin users.
Alerts:	Debian DSA-1066-1 2006-05-20

Comments (none posted)

phpbb2: multiple vulnerabilities

Package(s):	phpbb2	CVE #(s):	CVE-2005-3310 CVE-2005-3415 CVE-2005-3416 CVE-2005-3417 CVE-2005-3418 CVE-2005-3419 CVE-2005-3420 CVE-2005-3536 CVE-2005-3537
Created:	December 22, 2005	Updated:	February 11, 2008
Description:	The phpbb2 web forum has a number of vulnerabilities including: a web script injection problem, a protection mechanism bypass, a security check bypass, a remote global variable bypass, cross site scripting vulnerabilities, an SQL injection vulnerability, a remote regular expression modification problem, missing input sanitizing, and a missing request validation problem.
Alerts:	Debian DSA-925-1 2005-12-22

Comments (none posted)

phpmyadmin: multiple vulnerabilities

Package(s):	phpmyadmin	CVE #(s):	CVE-2006-6942 CVE-2006-6944 CVE-2007-1325 CVE-2007-1395 CVE-2007-2245
Created:	September 10, 2007	Updated:	March 19, 2009
Description:	Several remote vulnerabilities have been discovered in phpMyAdmin, a program to administrate MySQL over the web. The Common Vulnerabilities and Exposures project identifies the following problems: CVE-2007-1325: The PMA_ArrayWalkRecursive function in libraries/common.lib.php does not limit recursion on arrays provided by users, which allows context-dependent attackers to cause a denial of service (web server crash) via an array with many dimensions. CVE-2007-1395: Incomplete blacklist vulnerability in index.php allows remote attackers to conduct cross-site scripting (XSS) attacks by injecting arbitrary JavaScript or HTML in a (1) db or (2) table parameter value followed by an uppercase </SCRIPT> end tag, which bypasses the protection against lowercase </script>. CVE-2007-2245: Multiple cross-site scripting (XSS) vulnerabilities allow remote attackers to inject arbitrary web script or HTML via (1) the fieldkey parameter to browse_foreigners.php or (2) certain input to the PMA_sanitize function. CVE-2006-6942: Multiple cross-site scripting (XSS) vulnerabilities allow remote attackers to inject arbitrary HTML or web script via (1) a comment for a table name, as exploited through (a) db_operations.php, (2) the db parameter to (b) db_create.php, (3) the newname parameter to db_operations.php, the (4) query_history_latest, (5) query_history_latest_db, and (6) querydisplay_tab parameters to (c) querywindow.php, and (7) the pos parameter to (d) sql.php. CVE-2006-6944: phpMyAdmin allows remote attackers to bypass Allow/Deny access rules that use IP addresses via false headers.
Alerts:	Gentoo 200903-32 2009-03-18 Mandriva MDKSA-2007:199 2007-10-17 Debian DSA-1370-2 2007-09-10 Debian DSA-1370-1 2007-09-09

Comments (none posted)

phpPgAdmin: cross-site scripting

Package(s):	phppgadmin	CVE #(s):	CVE-2007-2865 CVE-2007-5728
Created:	June 18, 2007	Updated:	January 21, 2009
Description:	A cross-site scripting (XSS) vulnerability in sqledit.php in phpPgAdmin 4.1.1 allows remote attackers to inject arbitrary web script or HTML via the server parameter.
Alerts:	Debian DSA-1693-1 2008-12-27 Debian DSA-1693-2 2009-01-21 SuSE SUSE-SR:2007:024 2007-11-22 Fedora FEDORA-2007-1013 2007-07-11 Fedora FEDORA-2007-0469 2007-06-16

Comments (none posted)

postgresql: several vulnerabilities

Package(s):	postgresql	CVE #(s):	CVE-2007-3278 CVE-2007-3279 CVE-2007-3280
Created:	September 25, 2007	Updated:	February 1, 2008
Description:	PostgreSQL 8.1 and probably later and earlier versions, when local trust authentication is enabled and the Database Link library (dblink) is installed, allows remote attackers to access arbitrary accounts and execute arbitrary SQL queries via a dblink host parameter that proxies the connection from 127.0.0.1. (CVE-2007-3278) PostgreSQL 8.1 and probably later and earlier versions, when the PL/pgSQL (plpgsql) language has been created, grants certain plpgsql privileges to the PUBLIC domain, which allows remote attackers to create and execute functions, as demonstrated by functions that perform local brute-force password guessing attacks, which may evade intrusion detection. (CVE-2007-3279) The Database Link library (dblink) in PostgreSQL 8.1 implements functions via CREATE statements that map to arbitrary libraries based on the C programming language, which allows remote authenticated superusers to map and execute a function from any library, as demonstrated by using the system function in libc.so.6 to gain shell access. (CVE-2007-3280)
Alerts:	Red Hat RHSA-2008:0040-01 2008-02-01 Gentoo 200801-15 2008-01-29 Ubuntu USN-568-1 2008-01-14 Debian DSA-1463-1 2008-01-14 Debian DSA-1460-1 2008-01-13 Red Hat RHSA-2008:0039-01 2008-01-11 Red Hat RHSA-2008:0038-01 2008-01-11 Mandriva MDKSA-2007:188 2007-09-25

Comments (1 posted)

proftpd: authentication bypass

Package(s):	proftpd	CVE #(s):	CVE-2007-2165
Created:	June 21, 2007	Updated:	November 5, 2007
Description:	The ProFTPD Auth API has an authentication bypass vulnerability. When multiple simultaneous authentication modules are configured, the ProFTPD module that checks authentication is not necessarily the same module that retrieves authentication data. This can be used by remote attackers to bypass the authentication system.
Alerts:	Fedora FEDORA-2007-2613 2007-11-05 Mandriva MDKSA-2007:130 2007-06-20

Comments (none posted)

pulseaudio: denial of service

Package(s):	pulseaudio	CVE #(s):	CVE-2007-1804
Created:	May 30, 2007	Updated:	March 10, 2008
Description:	The pulseaudio network code suffers from a denial of service vulnerability exploitable by an unauthenticated attacker.
Alerts:	Mandriva MDVSA-2008:065 2007-03-09 Ubuntu USN-465-1 2007-05-25

Comments (none posted)

python: information disclosure

Package(s):	python	CVE #(s):	CVE-2007-2052
Created:	May 9, 2007	Updated:	July 30, 2009
Description:	Python 2.4 and 2.5 contain a bug in PyLocale_strxfrm() which could enable an attacker to read portions of unrelated memory.
Alerts:	CentOS CESA-2009:1176 2009-07-29 Red Hat RHSA-2009:1176-01 2009-07-27 Debian DSA-1620-1 2008-07-27 Debian DSA-1551-1 2008-04-19 Ubuntu USN-585-1 2008-03-11 Red Hat RHSA-2007:1076-02 2007-12-10 Red Hat RHSA-2007:1077-01 2007-12-10 Foresight FLEA-2007-0019-1 2007-05-21 rPath rPSA-2007-0104-1 2007-05-17 Mandriva MDKSA-2007:099 2007-05-08

Comments (none posted)

qemu: multiple vulnerabilities

Package(s):	qemu	CVE #(s):	CVE-2007-1320 CVE-2007-1321 CVE-2007-1322 CVE-2007-1323 CVE-2007-1366
Created:	May 1, 2007	Updated:	January 19, 2009
Description:	Several vulnerabilities have been discovered in the QEMU processor emulator, which may lead to the execution of arbitrary code or denial of service.
Alerts:	Fedora FEDORA-2008-11705 2008-12-24 Fedora FEDORA-2008-10000 2008-11-22 Fedora FEDORA-2008-9556 2008-11-12 SuSE SUSE-SR:2009:002 2009-01-19 Mandriva MDVSA-2008:162 2008-08-07 Fedora FEDORA-2008-4386 2008-05-28 Fedora FEDORA-2008-4604 2008-05-28 Fedora FEDORA-2007-713 2007-10-08 Debian DSA-1384-1 2007-10-05 Fedora FEDORA-2007-2270 2007-10-03 Red Hat RHSA-2007:0323-01 2007-10-02 Debian-Testing DTSA-38-1 2007-05-26 Debian DSA-1284-1 2007-05-01

Comments (none posted)

qgit: arbitrary code execution

Package(s):	qgit	CVE #(s):	CVE-2007-4631
Created:	September 10, 2007	Updated:	October 8, 2007
Description:	Not only does QGit construct a predictable file name here, and doesn't check if the files already exist, which can be leveraged into information leak or arbitrary file overwrite in case they're symlinks, but later on executes one of them. This is not just problem when /tmp is mounted with noexec option, but might be exploited into arbitrary code execution under time-dependent race condition.
Alerts:	Gentoo 200710-05 2007-10-07 Fedora FEDORA-2007-2108 2007-09-10

Comments (none posted)

qt: arbitrary code execution

Package(s):	qt	CVE #(s):	CVE-2007-3388
Created:	August 1, 2007	Updated:	December 10, 2007
Description:	Format string bugs were found in several Qt warning messages. Applications using Qt for processing certain data types could trigger them if the data caused Qt to print warnings. The bugs potentially allow to execute arbitrary code via specially crafted files (CVE-2007-3388).
Alerts:	Debian DSA-1426-1 2007-12-08 Gentoo 200708-16 2007-08-22 Slackware SSA:2007-222-03 2007-08-13 Foresight FLEA-2007-0042-1 2007-08-03 Ubuntu USN-495-1 2007-08-03 rPath rPSA-2007-0153-1 2007-08-01 Mandriva MDKSA-2007:151 2007-08-01 SuSE SUSE-SA:2007:048 2007-08-01 Red Hat RHSA-2007:0721-01 2007-07-31

Comments (none posted)

qt: buffer overflow

Package(s):	qt	CVE #(s):	CVE-2007-4137
Created:	September 14, 2007	Updated:	December 10, 2007
Description:	A buffer overflow was found in how Qt expanded malformed Unicode strings. If an application linked against Qt parsed a malicious Unicode string, it could lead to a denial of service or potentially allow for the execution of arbitrary code.
Alerts:	Debian DSA-1426-1 2007-12-08 Gentoo 200710-28 2007-10-25 rPath rPSA-2007-0204-1 2007-10-03 Foresight FLEA-2007-0059-1 2007-10-04 SuSE SUSE-SR:2007:019 2007-09-28 Ubuntu USN-513-1 2007-09-18 Fedora FEDORA-2007-703 2007-09-18 Fedora FEDORA-2007-2216 2007-09-18 Mandriva MDKSA-2007:183 2007-09-13

Comments (none posted)

quagga: denial of service

Package(s):	quagga	CVE #(s):	CVE-2007-4826
Created:	September 14, 2007	Updated:	October 25, 2010
Description:	The bgpd daemon in Quagga prior to 0.99.9 allowed remote BGP peers to cause a denial of service crash via a malformed OPEN message or COMMUNITY attribute.
Alerts:	CentOS CESA-2010:0785 2010-10-25 CentOS CESA-2010:0785 2010-10-20 Red Hat RHSA-2010:0785-01 2010-10-20 Debian DSA-1379-1 2007-10-01 Trustix TSLSA-2007-0028 2007-09-21 Fedora FEDORA-2007-2196 2007-09-18 Ubuntu USN-512-1 2007-09-15 Mandriva MDKSA-2007:182 2007-09-13

Comments (none posted)

quake: buffer overflow

Package(s):	quake3-bin	CVE #(s):	CVE-2006-2236
Created:	May 10, 2006	Updated:	January 12, 2009
Description:	Games based on the Quake 3 engine are vulnerable to a buffer overflow exploitable by a hostile game server.
Alerts:	Gentoo 200901-06 2009-01-11 Gentoo 200605-12 2006-05-10

Comments (none posted)

redhat-cluster-suite: denial of service

Package(s):	redhat-cluster-suite	CVE #(s):	CVE-2007-3380
Created:	July 19, 2007	Updated:	November 14, 2007
Description:	The redhat cluster suite's cluster manager is vulnerable to a remote attack. Attackers can connect to the DLM port and block subsequent DLM operations, resulting in a denial of service.
Alerts:	Ubuntu USN-489-1 2007-07-19 Red Hat RHSA-2007:0940-01 2007-10-22 Ubuntu USN-489-2 2007-07-19

Comments (1 posted)

rsync: off-by-one errors

Package(s):	rsync	CVE #(s):	CVE-2007-4091
Created:	August 20, 2007	Updated:	December 3, 2007
Description:	Multiple off-by-one errors in the sender.c in rsync 2.6.9 might allow remote attackers to execute arbitrary code via directory names that are not properly handled when calling the f_name function.
Alerts:	Slackware SSA:2007-335-01 2007-12-03 Gentoo 200709-13 2007-09-20 Debian DSA-1360 2007-08-28 Foresight FLEA-2007-0047-1 2007-08-23 rPath rPSA-2007-0168-1 2007-08-22 Ubuntu USN-500-1 2007-08-20 Mandriva MDKSA-2007:166 2007-08-18

Comments (1 posted)

samba: incorrect group assignment

Package(s):	samba	CVE #(s):	CVE-2007-4138
Created:	September 12, 2007	Updated:	November 15, 2007
Description:	From the Samba advisory: When the rfc2307 or sfu nss_info plugin has been enabled, in the absence of either the RFC2307 or SFU primary group attribute, Winbind will assign a primary group ID of 0 to the domain user queried using the getpwnam() C library call.
Alerts:	Red Hat RHSA-2007:1017-01 2007-11-15 Red Hat RHSA-2007:1016-01 2007-11-15 rPath rPSA-2007-0184-1 2007-09-14 Slackware SSA:2007-255-02 2007-09-13 Fedora FEDORA-2007-2145 2007-09-12

Comments (1 posted)

star: directory traversal vulnerability

Package(s):	star	CVE #(s):	CVE-2007-4134
Created:	August 28, 2007	Updated:	October 23, 2007
Description:	Star saves many files together into a single tape or disk archive, and can restore individual files from the archive. Star supports ACL. Version 1.5a84 fixes a directory traversal vulnerability.
Alerts:	Gentoo 200710-23 2007-10-22 Foresight FLEA-2007-0051-1 2007-09-06 Red Hat RHSA-2007:0873-01 2007-09-04 Fedora FEDORA-2007-1852 2007-08-27

Comments (none posted)

streamripper: buffer overflow

Package(s):	streamripper	CVE #(s):	CVE-2007-4337
Created:	September 14, 2007	Updated:	December 9, 2008
Description:	Chris Rohlf discovered several boundary errors in the httplib_parse_sc_header() function when processing HTTP headers.
Alerts:	Debian DSA-1683-1 2008-12-08 Gentoo 200709-03 2007-09-13

Comments (none posted)

Sun JDK/JRE: multiple vulnerabilities

Package(s):	Sun JDK/JRE	CVE #(s):	CVE-2007-2435 CVE-2007-2788 CVE-2007-2789
Created:	June 1, 2007	Updated:	April 18, 2008
Description:	An unspecified vulnerability involving an "incorrect use of system classes" was reported by the Fujitsu security team. Additionally, Chris Evans from the Google Security Team reported an integer overflow resulting in a buffer overflow in the ICC parser used with JPG or BMP files, and an incorrect open() call to /dev/tty when processing certain BMP files.
Alerts:	Gentoo 200804-20 2008-04-17 Red Hat RHSA-2007:1086-01 2007-12-12 Red Hat RHSA-2007:0817-01 2007-08-06 SuSE SUSE-SA:2007:045 2007-07-18 Gentoo 200706-08 2007-06-26 Gentoo 200705-23 2007-05-31

Comments (none posted)

sylpheed: format string vulnerability

Package(s):	sylpheed	CVE #(s):	CVE-2007-2958
Created:	August 28, 2007	Updated:	October 26, 2007
Description:	Ulf Harnhammar (Secunia Research) has discovered a format string vulnerability in sylpheed and claws-mail in inc_put_error() function in src/inc.c when displaying POP3 error reply. The problem can be exploited by malicious POP3 server via specially crafted POP3 server replies containing format specifiers. See this Secunia advisory for more information.
Alerts:	Gentoo 200710-29 2007-10-25 Fedora FEDORA-2007-2009 2007-09-04 Fedora FEDORA-2007-1841 2007-08-27

Comments (none posted)

sysstat: insecure temporary files

Package(s):	sysstat	CVE #(s):	CVE-2007-3852
Created:	August 20, 2007	Updated:	September 23, 2011
Description:	The init script (sysstat.in) in sysstat 5.1.2 up to 7.1.6 creates /tmp/sysstat.run insecurely, which allows local users to execute arbitrary code.
Alerts:	CentOS CESA-2011:1005 2011-09-22 Scientific Linux SL-syss-20110721 2011-07-21 Red Hat RHSA-2011:1005-01 2011-07-21 Fedora FEDORA-2007-675 2007-08-27 Fedora FEDORA-2007-1697 2007-08-20

Comments (1 posted)

t1lib: buffer overflow

Package(s):	t1lib	CVE #(s):	CVE-2007-4033
Created:	September 20, 2007	Updated:	February 12, 2008
Description:	T1lib, an enhanced rasterizer for X11 Type 1 fonts, does not properly perform bounds checking. An attacker can send specially crafted input to applications linked against the library in order to create a buffer overflow, resulting in a denial of service or the execution of arbitrary code.
Alerts:	Foresight FLEA-2008-0006-1 2008-02-11 rPath rPSA-2008-0007-1 2008-01-04 Mandriva MDKSA-2007:230 2007-11-20 Fedora FEDORA-2007-3308 2007-11-20 Fedora FEDORA-2007-750 2007-11-21 Fedora FEDORA-2007-3390 2007-11-20 Red Hat RHSA-2007:1027-02 2007-11-08 Debian DSA-1390-1 2007-10-18 Gentoo 200710-12 2007-10-12 Fedora FEDORA-2007-2343 2007-09-28 Mandriva MDKSA-2007:189 2007-09-27 Ubuntu USN-515-1 2007-09-19

Comments (none posted)

tar: symlink path traversal vulnerability

Package(s):	tar	CVE #(s):	CVE-2007-4131
Created:	August 23, 2007	Updated:	December 28, 2007
Description:	The tar utility has a symlink path traversal vulnerability involving extracted archives. Maliciously created tar archives can be used to write arbitrary data to files that the tar user has write access to.
Alerts:	Debian DSA-1438-1 2007-12-28 Gentoo 200709-09 2007-09-15 Mandriva MDKSA-2007:173 2007-09-04 Fedora FEDORA-2007-683 2007-08-30 SuSE SUSE-SR:2007:018 2007-08-31 Fedora FEDORA-2007-1890 2007-08-29 Ubuntu USN-506-1 2007-08-28 rPath rPSA-2007-0172-1 2007-08-25 Foresight FLEA-2007-0049-1 2007-08-27 Red Hat RHSA-2007:0860-01 2007-08-23

Comments (none posted)

tcpdump: integer overflow

Package(s):	tcpdump	CVE #(s):	CVE-2007-3798
Created:	July 20, 2007	Updated:	November 15, 2007
Description:	An integer overflow in print-bgp.c in the BGP dissector in tcpdump 3.9.6 and earlier allows remote attackers to execute arbitrary code via crafted TLVs in a BGP packet, related to an unchecked return value.
Alerts:	Red Hat RHSA-2007:0387-02 2007-11-15 Red Hat RHSA-2007:0368-03 2007-11-07 Slackware SSA:2007-230-01 2007-08-20 Debian DSA-1353-1 2007-08-11 Fedora FEDORA-2007-654 2007-08-01 Fedora FEDORA-2007-1361 2007-07-31 Ubuntu USN-492-1 2007-07-30 Gentoo 200707-14 2007-07-28 Mandriva MDKSA-2007:148 2007-07-25 rPath rPSA-2007-0147-1 2007-07-20

Comments (none posted)

tcpdump: denial of service

Package(s):	tcpdump	CVE #(s):	CVE-2007-1218
Created:	March 5, 2007	Updated:	November 15, 2007
Description:	Off-by-one buffer overflow in the parse_elements function in the 802.11 printer code (print-802_11.c) for tcpdump 3.9.5 and earlier allows remote attackers to cause a denial of service (crash) via a crafted 802.11 frame. NOTE: this was originally referred to as heap-based, but it might be stack-based.
Alerts:	Red Hat RHSA-2007:0387-02 2007-11-15 Mandriva MDKSA-2007:155 2007-08-09 Debian DSA-1272-1 2007-03-22 Fedora FEDORA-2007-348 2007-03-15 Fedora FEDORA-2007-347 2007-03-15 Mandriva MDKSA-2007:056 2006-03-08 Ubuntu USN-429-1 2007-03-06 rPath rPSA-2007-0048-1 2007-03-03

Comments (none posted)

tcp-wrappers: unauthorized access

Package(s):	tcp-wrappers	CVE #(s):	CVE-2007-5137
Created:	August 30, 2007	Updated:	October 13, 2007
Description:	The TCP wrapper library can improperly allow connections to services that do not have server-side connection details specified. Remote attackers can connect to blocked services.
Alerts:	Ubuntu USN-507-1 2007-08-30

Comments (none posted)

terminal: arbitrary code execution

Package(s):	terminal	CVE #(s):	CVE-2007-3770
Created:	August 13, 2007	Updated:	December 19, 2007
Description:	A vulnerability was found in the Xfce terminal program: Lasse Karkkainen discovered that the function terminal_helper_execute() in file terminal-helper.c does not properly escape the URIs before processing.
Alerts:	Fedora FEDORA-2007-4368 2007-12-15 Fedora FEDORA-2007-4385 2007-12-15 Debian DSA-1393-1 2007-10-23 Fedora FEDORA-2007-1620 2007-08-15 Ubuntu USN-497-1 2007-08-14 Gentoo 200708-07 2007-08-11

Comments (none posted)

tetex: buffer overflow

Package(s):	tetex	CVE #(s):	CVE-2007-0650
Created:	May 8, 2007	Updated:	May 13, 2008
Description:	A buffer overflow in the open_sty function in mkind.c for makeindex 2.14 in teTeX might allow user-assisted remote attackers to overwrite files and possibly execute arbitrary code via a long filename. NOTE: other overflows exist but might not be exploitable, such as a heap-based overflow in the check_idx function.
Alerts:	Gentoo 200805-13 2008-05-12 Gentoo 200709-17 2007-09-27 Mandriva MDKSA-2007:109 2007-05-23 rPath rPSA-2007-0092-1 2007-05-07

Comments (1 posted)

tomcat: directory traversal

Package(s):	tomcat	CVE #(s):	CVE-2007-0450
Created:	May 2, 2007	Updated:	February 27, 2008
Description:	Versions of tomcat prior to 5.5.22 do not properly filter filename separator characters, enabling information disclosure attacks.
Alerts:	SuSE SUSE-SR:2007:015 2007-08-03 Mandriva MDKSA-2007:241 2007-12-10 Red Hat RHSA-2007:0360-01 2007-05-24 Red Hat RHSA-2007:0328-01 2007-05-24 Fedora FEDORA-2007-514 2007-05-21 Red Hat RHSA-2007:0326-01 2007-05-21 Red Hat RHSA-2007:0327-01 2007-05-14 Gentoo 200705-03 2007-05-01

Comments (none posted)

tomcat: cross-site scripting

Package(s):	tomcat	CVE #(s):	CVE-2007-2449 CVE-2007-2450
Created:	July 17, 2007	Updated:	February 17, 2009
Description:	Some JSPs within the 'examples' web application did not escape user provided data. If the JSP examples were accessible, this flaw could allow a remote attacker to perform cross-site scripting attacks (CVE-2007-2449). Note: it is recommended the 'examples' web application not be installed on a production system. The Manager and Host Manager web applications did not escape user provided data. If a user is logged in to the Manager or Host Manager web application, an attacker could perform a cross-site scripting attack (CVE-2007-2450).
Alerts:	SuSE SUSE-SR:2009:004 2009-02-17 Fedora FEDORA-2008-8130 2008-09-16 SuSE SUSE-SR:2008:007 2008-03-28 Fedora FEDORA-2008-1603 2008-02-13 Fedora FEDORA-2008-1467 2008-02-13 Debian DSA-1468-1 2008-01-20 Mandriva MDKSA-2007:241 2007-12-10 Fedora FEDORA-2007-3474 2007-11-17 Fedora FEDORA-2007-3456 2007-11-17 Red Hat RHSA-2007:0569-01 2007-07-17

Comments (1 posted)

tomcat: multiple vulnerabilities

Package(s):	tomcat	CVE #(s):	CVE-2007-3382 CVE-2007-3385 CVE-2007-3386
Created:	September 26, 2007	Updated:	September 13, 2010
Description:	Tomcat was found treating single quote characters -- ' -- as delimiters in cookies. This could allow remote attackers to obtain sensitive information, such as session IDs, for session hijacking attacks (CVE-2007-3382). It was reported Tomcat did not properly handle the following character sequence in a cookie: \" (a backslash followed by a double-quote). It was possible remote attackers could use this failure to obtain sensitive information, such as session IDs, for session hijacking attacks (CVE-2007-3385). A cross-site scripting (XSS) vulnerability existed in the Host Manager Servlet. This allowed remote attackers to inject arbitrary HTML and web script via crafted requests (CVE-2007-3386).
Alerts:	Mandriva MDVSA-2010:176 2010-09-12 SuSE SUSE-SR:2009:004 2009-02-17 Fedora FEDORA-2008-8130 2008-09-16 Red Hat RHSA-2008:0195-01 2008-04-28 SuSE SUSE-SR:2008:005 2008-03-06 Fedora FEDORA-2008-1603 2008-02-13 Fedora FEDORA-2008-1467 2008-02-13 Debian DSA-1447-1 2008-01-03 Mandriva MDKSA-2007:241 2007-12-10 Fedora FEDORA-2007-3456 2007-11-17 Fedora FEDORA-2007-3474 2007-11-17 Red Hat RHSA-2007:0950-01 2007-11-05 Red Hat RHSA-2007:0876-01 2007-10-11 Red Hat RHSA-2007:0871-01 2007-09-26

Comments (none posted)

vim: arbitrary code execution

Package(s):	vim	CVE #(s):	CVE-2007-2953
Created:	July 30, 2007	Updated:	November 27, 2008
Description:	vim is vulnerable to a user-assisted attack in which vim may execute arbitrary code when helptags is run on data that has been maliciously crafted.
Alerts:	CentOS CESA-2008:0580 2008-11-26 CentOS CESA-2008:0617 2008-11-25 Red Hat RHSA-2008:0617-01 2008-11-25 Red Hat RHSA-2008:0580-01 2008-11-25 Debian DSA-1364-2 2007-09-19 Debian DSA-1364-1 2007-09-01 Ubuntu USN-505-1 2007-08-28 Mandriva MDKSA-2007:168 2007-08-21 rPath rPSA-2007-0151-1 2007-07-31 Foresight FLEA-2007-0036-1 2007-07-30

Comments (none posted)

vixie-cron: weak permissions may cause errors

Package(s):	vixie-cron	CVE #(s):	CVE-2007-1856
Created:	April 17, 2007	Updated:	December 4, 2007
Description:	During an internal audit, Raphael Marichez of the Gentoo Linux Security Team found that Vixie Cron has weak permissions set on Gentoo, allowing for a local user to create hard links to system and users cron files, while a st_nlink check in database.c will generate a superfluous error.
Alerts:	Mandriva MDKSA-2007:234 2007-12-03 Red Hat RHSA-2007:0345-01 2007-05-17 Gentoo 200704-11 2007-04-16

Comments (1 posted)

vlc: several vulnerabilities

Package(s):	vlc	CVE #(s):	CVE-2007-3316 CVE-2007-3467 CVE-2007-3468
Created:	July 10, 2007	Updated:	March 10, 2008
Description:	Several remote vulnerabilities have been discovered in the VideoLan multimedia player and streamer, which may lead to the execution of arbitrary code.
Alerts:	Gentoo 200803-13 2008-03-07 Gentoo 200707-12 2007-07-28 Debian DSA-1332-1 2007-07-09

Comments (none posted)

wireshark: multiple vulnerabilities

Package(s):	wireshark	CVE #(s):	CVE-2007-3390 CVE-2007-3392 CVE-2007-3393
Created:	June 28, 2007	Updated:	February 27, 2008
Description:	The wireshark network traffic analyzer has three vulnerabilities that can be used to create a denial of service. These include off-by-one overflows in the iSeries dissector, vulnerabilities in the MMS and SSL dissectors that can cause an infinite loop and an off-by-one overflow in the DHCP/BOOTP dissector.
Alerts:	SuSE SUSE-SR:2007:015 2007-08-03 Red Hat RHSA-2008:0059-01 2008-01-21 Red Hat RHSA-2007:0709-02 2007-11-15 Red Hat RHSA-2007:0710-04 2007-11-07 Gentoo 200708-12 2007-08-16 Fedora FEDORA-2007-628 2007-07-09 rPath rPSA-2007-0137-1 2007-07-11 Mandriva MDKSA-2007:145 2007-07-10 Fedora FEDORA-2007-0982 2007-07-09 Debian DSA-1322-1 2007-06-27

Comments (none posted)

XFree86 X.org: integer overflows

Package(s):	xfree86 x.org	CVE #(s):	CVE-2007-1003 CVE-2007-1667 CVE-2007-1351 CVE-2007-1352
Created:	April 3, 2007	Updated:	August 11, 2009
Description:	iDefense reported an integer overflow flaw in the XFree86 XC-MISC extension. A malicious authorized client could exploit this issue to cause a denial of service (crash) or potentially execute arbitrary code with root privileges on the XFree86 server. (CVE-2007-1003) iDefense reported two integer overflows in the way X.org handled various font files. A malicious local user could exploit these issues to potentially execute arbitrary code with the privileges of the X.org server. (CVE-2007-1351, CVE-2007-1352) An integer overflow flaw was found in the XFree86 XGetPixel() function. Improper use of this function could cause an application calling it to function improperly, possibly leading to a crash or arbitrary code execution. (CVE-2007-1667)
Alerts:	Debian DSA-1858-1 2009-08-10 SuSE SUSE-SR:2008:008 2008-04-04 Debian DSA-1454-1 2008-01-07 Debian DSA-1294-1 2007-05-17 Gentoo 200705-10 2007-05-08 Gentoo 200705-06 2007-05-05 Gentoo 200705-02 2007-05-01 Ubuntu USN-453-2 2007-04-26 SuSE SUSE-SA:2007:027 2007-04-20 Slackware SSA:2007-109-01 2007-04-20 Ubuntu USN-453-1 2007-04-18 Red Hat RHSA-2007:0157-01 2007-04-16 Red Hat RHSA-2007:0150-01 2007-04-16 Mandriva MDKSA-2007:079-1 2007-04-11 Mandriva MDKSA-2007:080-1 2007-04-10 Mandriva MDKSA-2007:081-1 2007-04-10 Fedora FEDORA-2007-427 2007-04-10 Fedora FEDORA-2007-426 2007-04-10 Fedora FEDORA-2007-425 2007-04-10 Fedora FEDORA-2007-424 2007-04-10 Fedora FEDORA-2007-423 2007-04-09 Fedora FEDORA-2007-422 2007-04-09 Foresight FLEA-2007-0009-1 2007-04-05 Mandriva MDKSA-2007:080 2007-04-04 Mandriva MDKSA-2007:081 2007-04-04 Mandriva MDKSA-2007:079 2007-04-04 rPath rPSA-2007-0065-1 2007-04-04 Ubuntu USN-448-1 2007-04-03 Red Hat RHSA-2007:0132-01 2007-04-03 Red Hat RHSA-2007:0127-01 2007-04-03 Red Hat RHSA-2007:0126-01 2007-04-03 Red Hat RHSA-2007:0125-01 2007-04-03

Comments (none posted)

xine-lib: arbitrary code execution

Package(s):	xine-lib	CVE #(s):	CVE-2007-1387
Created:	March 13, 2007	Updated:	April 1, 2008
Description:	Moritz Jodeit discovered that the DirectShow loader of Xine did not correctly validate the size of an allocated buffer. By tricking a user into opening a specially crafted media file, an attacker could execute arbitrary code with the user's privileges.
Alerts:	Debian DSA-1536-1 2008-03-31 Mandriva MDKSA-2007:062 2007-03-13 Mandriva MDKSA-2007:061 2007-03-13 Ubuntu USN-435-1 2007-03-12

Comments (none posted)

xine-lib: buffer overflow

Package(s):	xine-lib	CVE #(s):	CVE-2006-1664
Created:	April 27, 2006	Updated:	February 27, 2008
Description:	xine-lib does an improper input data boundary check on MPEG streams. A specially crafted MPEG file can be created that can cause arbitrary code execution when the file is accessed.
Alerts:	Gentoo 200802-12 2008-02-26 Gentoo 200604-16 2006-04-26

Comments (none posted)

xmms: BMP handling vulnerability

Package(s):	xmms	CVE #(s):	CVE-2007-0653 CVE-2007-0654
Created:	March 28, 2007	Updated:	July 26, 2011
Description:	xmms suffers from vulnerabilities in its handling of BMP images. Should a hostile image be included in an xmms skin, it could lead to code execution on the user's system.
Alerts:	Fedora FEDORA-2011-9421 2011-07-16 Fedora FEDORA-2011-9413 2011-07-16 Debian DSA-1277-1 2007-04-04 Mandriva MDKSA-2007:071 2007-03-29 Ubuntu USN-445-1 2007-03-27

Comments (none posted)

X.org: temp file vulnerability

Package(s):	X.org	CVE #(s):	CVE-2007-3103
Created:	July 12, 2007	Updated:	July 2, 2009
Description:	The X.Org X11 xfs font server has a temp file vulnerability in the startup script. A local user can modify the permissions of the script in order to elevate their local privileges.
Alerts:	Fedora FEDORA-2009-3651 2009-04-14 Fedora FEDORA-2009-3666 2009-04-14 Debian DSA-1342-1 2007-07-30 rPath rPSA-2007-0141-1 2007-07-17 Foresight FLEA-2007-0031-1 2007-07-12 Red Hat RHSA-2007:0520-01 2007-07-12 Red Hat RHSA-2007:0519-01 2007-07-12

Comments (none posted)

xorg-server: local privilege escalation

Package(s):	xorg-server	CVE #(s):	CVE-2007-4730
Created:	September 10, 2007	Updated:	January 24, 2008
Description:	Aaron Plattner discovered a buffer overflow in the Composite extension of the X.org X server, which can lead to local privilege escalation.
Alerts:	Mandriva MDVSA-2008:022 2008-01-23 Gentoo 200710-16 2007-10-14 Ubuntu USN-514-1 2007-09-18 Red Hat RHSA-2007:0898-01 2007-09-19 rPath rPSA-2007-0187-1 2007-09-14 Mandriva MDKSA-2007:178 2007-09-11 Debian DSA-1372-1 2007-09-09

Comments (none posted)

xterm: local user unauthorized access

Package(s):	xterm	CVE #(s):	CVE-2007-2797
Created:	August 27, 2007	Updated:	November 15, 2007
Description:	Previous versions of the xterm package assigned incorrect ownership and write permissions to pseudo-terminal devices, permitting local users to direct output to other users' xterm sessions.
Alerts:	Red Hat RHSA-2007:0701-02 2007-11-15 rPath rPSA-2007-0169-1 2007-08-23 Foresight FLEA-2007-0048-1 2007-08-23

Comments (1 posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current 2.6 prepatch is 2.6.23-rc9, released on October 1. This -rc release was unexpected, but there were enough fixes added since -rc8 that Linus felt one more cycle was called for. The final 2.6.23 release should happen almost any time.

There have been about a dozen patches added to the mainline repository since -rc9.

The current -mm tree is 2.6.23-rc8-mm2. Recent changes to -mm include delayed allocation support for ext4 and a number of fixes. Andrew notes that -mm now has almost 32MB of patches relative to the mainline - an indication of what is to come once the 2.6.24 merge window opens.

Looking forward: it appears that the 2.6.24 cycle will begin with the i386/x86_64 merger. More information about 2.6.24 can be found in Andrew Morton's 2.6.24 merge plans document. It looks like 2.6.24 will include a bunch of memory management work, more anti-fragmentation patches, per-device write throttling, the LSM non-modules patch, file-based capabilities, more memory layout randomization, control groups (formerly containers), PID namespaces, kernel markers, and much more. Remember that this list covers only patches to be merged by Andrew; the bulk of the code going into 2.6.24 will get there directly from the subsystem maintainers.

Comments (none posted)

Kernel development news

Quotes of the week

-- Ingo Molnar

Andrew Morton

-- Ted Ts'o

Comments (8 posted)

Linux driver project gets a full-time leader

The Linux Driver Project (LDP) just got a big boost, courtesy of Novell and Greg Kroah-Hartman. The project was announced last January to much acclaim, but has languished since, buried under Kroah-Hartman's "day job" and Linux kernel development work. Now, he will be able to devote much more time to the project as his employer, Novell, has shifted his job responsibilities to work full-time on the LDP.

The original project announcement was released in conjunction with the Freedom HEC conference and was described by Kroah-Hartman as a "lame publicity stunt", because it just reiterated the standard Linux driver development model: with some hardware and some information, a driver for your device will be written. There was a new wrinkle, though; an arrangement worked out with the Linux Foundation to allow driver developers to sign non-disclosure agreements (NDAs) with hardware vendors to get access to documentation and other information about the device. NDAs for driver development are controversial in some quarters, but are often required by hardware vendors.

There are numerous benefits for Linux: the drivers will all be licensed under the GPL, will get merged into the mainline tree, and be available for all Linux users. Other free operating systems may be able to use the source to write drivers for their systems, as well. Kroah-Hartman notes that a surprising added benefit is for new kernel developers:

Now that he has time to devote to LDP, Kroah-Hartman has put together two mailing lists along with a wiki to track the project. There is a mailing list for each of the two main roles, developers and project managers. The role of a project manager will be to facilitate the development, making sure that the driver hacker has what they need to get the job done and keeping the company, for whom the driver is being written, informed of the status. In short, they will shepherd an individual driver in much the same way that Kroah-Hartman is coordinating the LDP as a whole.

In less than a week since the project restart, there are five driver projects up for grabs, including a "clean-up and get merged" project that would be suitable as a first driver for someone just starting out in Linux driver development. Project managers are lining up to take on the drivers as well. The numbers of volunteers have grown, but as Kroah-Hartman notes, publicity is something the project still needs:

Already, there are drivers for many different kinds of devices in the pipeline:

Kroah-Hartman plans to reconnect with various companies that contacted him since January, but fell by the wayside. As that happens and the word gets out about the project, there should be driver development projects suitable for a wide range of interests and various levels of kernel experience. By providing a self-contained project that is targeted at inclusion in the mainline, more developers will be exposed to that process, which should expand the ranks of kernel hackers.

Linux already supports more hardware than any operating system has before and the LDP will only extend that lead. There are huge benefits for Linux, the developers and project managers, the companies whose devices will be supported, as well as for distributors like Novell. There may be complaints about signing NDAs, but the drivers will be free, not obfuscated; once companies see how easy it is to get a high-quality driver into the kernel, they will certainly come back for more. This can only be a good thing for all free software systems, not just Linux.

Comments (6 posted)

What's in the realtime tree

It has been almost exactly three years since Sven-Thorsten Dietrich posted a set of realtime improvements to the linux-kernel list. That particular body of code was upstaged by the realtime preemption work done by Ingo Molnar and others, but it deserves some credit for kicking off a development effort which continues to this day. After three years, many parts of the realtime preemption patch set have been merged into the mainline kernel, including dynamic tick support, a rewritten interrupt subsystem, mutexes, priority inheritance, high-resolution timers, and more. At this point, we are all running kernels which have benefited from the realtime preemption project.

The job of merging the realtime preemption work into the mainline is not complete, though. Indeed, a look at the 2.6.23-rc8-rt1 tree announcement shows that there are nearly 400 individual patches sitting there. This seems like a good opportunity to have a look at the realtime tree and see what remains to be merged.

The core of this patch set remains the realtime mutex code. When the kernel is configured for realtime operation, a bunch of (improved, but still scary) preprocessor magic causes normal spinlocks to be replaced by realtime mutexes, which have different properties. In particular, realtime mutexes are fully preemptible and have priority inheritance. With most kernel spinlocks replaced by these mutexes, there are few places in the kernel which are able to cause arbitrary latencies.

Merging realtime mutexes should, in theory, not be a problem; they are not actually used unless explicitly configured into the kernel, and it is assumed that most users will not configure things that way. Such a fundamental change to a core mutual exclusion mechanism will always raise eyebrows, though. So there have been no attempts to merge this code so far, and it is likely that most of the other parts of the realtime tree will find their way into the mainline first.

Code which could go in sooner is the threaded interrupt handlers patch. Putting interrupt handlers into threads allows them to be scheduled along with most other system activities and eliminates another potential source of latency. It also can improve the robustness of the system and make it easier to find bugs in interrupt code. So this patch could be merged and possibly even made the default - though there will always be a small number of interrupt handlers which must be run directly.

Also in the realtime tree is a patch which moves all software interrupt processing into dedicated threads. Then there is a patch which allows hardware interrupt handling threads to process any pending software interrupts before yielding the processor. This optimization avoids the need for a context switch to a separate software IRQ thread to get those interrupts delivered.

One of the sticking points with the realtime patches has been their interaction with the read-copy-update mechanism. The current code requires that preemption be disabled while references to RCU-protected data structures exist, but disabling preemption ruins the guarantees that the realtime code is trying to provide. The answer is a somewhat more complicated, preemptible RCU implementation. With luck, LWN will have an article on how preemptible RCU works in the near future.

Nick Piggin's lockless pagecache patches have found their way into the realtime tree. These patches make a number of low-level changes to the memory management and radix tree code so that some pagecache operations can be done without taking any locks. This code has been in circulation for some time without making it into the mainline, but it seems like a win in a number of scalability situations. Another patch (by Peter Zijlstra) gets rid of the locking in the kmap() code, improving latencies in systems using high memory.

The wisdom of allowing Java programs to mess with physical memory is not a topic which should need further discussion here. Another patch which has been out of the mainline for quite some time - and likely to remain that way - is Ted Ts'o's /dev/rmem facility. This device allows direct access to physical memory - a feature which is required on any system which wants to pass the realtime Java conformance tests. The wisdom of allowing Java programs to mess with physical memory is not a topic which should need further discussion here.

The realtime tree contains an extensive set of tools for tracking down parts of the kernel which cause excessive latencies. This code has, over the years, been put to good use in identifying and breaking up kernel code which hogs the processor unnecessarily. These patches would seem like a good match for the mainline, especially given recent discussions on the value of adding more instrumentation to the kernel. The first step in solving problems is being able to measure them.

For reasons which are unclear to your editor, the realtime tree contains the venerable realtime security module, which was definitively refused entry into the mainline a few years ago. The module is marked as being obsolete - but it is still there.

Quite a few other changes can be found in this tree. The SLUB allocator is not an option for realtime kernels. Instead, this tree uses a modified version of the slab allocator which replaces interrupt-based single-CPU locking with a set of specific per-CPU locks. The global files_lock has been removed in favor of tightly-locked per-CPU lists. To help with the creation of such lists, a new locked-list type has been added. The tasklet code has been reworked for better threading, but the tasklet elimination patch is not present. There's also quite a few architecture-specific patches adding various features (such as clockevents) needed by the realtime tree and fixing problems.

All told, there is a lot of code sitting in the realtime tree despite all of the mainline merging which has happened over the last couple of years or so. The stated plan is to merge most of this code in the not-too-distant future, but it is not clear when that will happen. In particular, some of the core realtime developers are likely to be severely distracted by the i386/x86_64 merger during the 2.6.24 cycle, so they may not manage to move much of the realtime code toward the mainline.

Comments (4 posted)

SMACK meets the One True Security Module

The Simplified Mandatory Access Control Kernel is a security module designed to harden Linux systems through the addition of mandatory access control policies; it was covered here last August. Like SELinux, SMACK works by attaching labels to processes, files, and other system objects and implementing rules describing what kinds of access are allowed by specific combinations of labels. Unlike SELinux, though, SMACK was designed specifically for simplicity of administration.

The posting of version 3 of the SMACK patch inspired a certain amount of discussion. Andrew Morton's take led things off:

Andrew concluded by suggesting that the SMACK patch should be merged for 2.6.24. There was some discussion about specific pieces of the patch (some developers are more impressed by CIPSO network labels than others), but there does not seem to be a whole lot of opposition to merging the SMACK security module. It is generally seen as being well-written code which makes sense from a security point of view.

There was one predictable exception, though: whenever a new security module is considered for merging the SELinux developers tend to oppose it. This time, James Morris voiced a more general complaint: SMACK would become the second in-kernel user of the Linux security module (LSM) framework. That, in turn, would make it almost impossible to remove LSM from the kernel. James claims:

The SELinux programmers, it seems, would rather that SELinux became the one security framework supported by Linux, with all development effort going into making SELinux better.

The problem, of course, is that, even after a few years with only SELinux in the kernel, there has not been a glut of application developers working to support it. The vision of each application shipping with an SELinux policy file has not come to be. Some progress has been made in the creation of higher-level tools for the management of SELinux policies, and the Fedora and Red Hat developers have come a long way toward making a general-purpose distribution work with a limited set of SELinux policies, but SELinux simply remains too complex for most people to deal with. SELinux may work out of the box on an RHEL system, but as soon as the system administrator runs into something which breaks, chances are that SELinux will be turned off.

The SELinux developers would presumably argue that the way to address these problems is to focus on a single security framework within the kernel. Rather than create competing, simplified frameworks, it would be better to implement approaches like AppArmor or SMACK within SELinux and, in the process, make SELinux better. Those developers argue that pluggable security modules, like pluggable schedulers, succeed only in splitting development effort and preventing the creation of a truly general solution:

The answering argument is that there are many security environments and differing sets of user needs; there is no sign that a single security approach can ever work in all situations. And, even if such a unified approach were possible, getting security developers to agree on it would still be a major challenge. Ted Ts'o writes:

The LSM architecture was a result of the very first kernel summit, where Linus stated that he had no wish to choose between the various security ideas in circulation and, instead, wanted the kernel to be able to support all of them. He has not changed his mind since; he still doesn't see any imminent consensus on security approaches, and still wants Linux to be flexible in this regard. So his pronouncement was:

So it looks like the way is clear for a merger of SMACK in 2.6.24. Once that happens, it would not be surprising to see another push made by the developers of security modules like AppArmor and TOMOYO Linux; in fact, the TOMOYO Linux patches have just been reposted. In the end, SELinux will, despite the apparent wishes of its developers, have to compete with other security approaches for attention from developers, distributors, and users. There will be no One True Security Module for Linux in the foreseeable future.

Comments (13 posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 2.6.23-rc9 and a heads-up for the 2.6.24 series... (October 2, 2007)

• Steven Rostedt: 2.6.23-rc9-rt1. (October 3, 2007)

• Andrew Morton: 2.6.23-rc8-mm2. (September 27, 2007)

• Steven Rostedt: 2.6.23-rc8-rt1. (September 27, 2007)

Core kernel code

• Vegard Nossum: New kernel-message logging API (take 2). (September 28, 2007)

• Ingo Molnar: printk: add KERN_CONT annotation. (October 2, 2007)

• Pierre Peiffer: System V IPC: new kernel API to change an ID. (October 1, 2007)

• Pierre Peiffer: [RFC][PATCH 2/2] System V IPC: new IPC_SETID command to modify an ID. (October 1, 2007)

• Paul Jackson: cpuset and sched domains: sched_load_balance flag. (October 1, 2007)

• Dhaval Giani: Add sysfs control to modify a user's cpu share. (October 1, 2007)

• Steven Rostedt: RCU preemption priority boosting. (October 3, 2007)

Development tools

• Subrata Modak: [ANNOUNCE] The Linux Test Project has been Released for SEPTEMBER 2007. (October 1, 2007)

• Mathieu Desnoyers: Linux Kernel Markers for 2.6.23-rc8-mm2. (October 1, 2007)

Device drivers

• Greg KH: State of the Linux Driver Core Subsystem for 2.6.23-rc8. (September 27, 2007)

• Greg KH: State of the Linux USB Subsystem for 2.6.23-rc8. (September 27, 2007)

• Greg KH: State of the Linux PCI Subsystem for 2.6.23-rc8. (September 27, 2007)

• Mark Gross: QoS power Management enabling patch set. (October 1, 2007)

• Haavard Skinnemoen: Atmel USBA UDC driver, take 2. (October 1, 2007)

• Boaz Harrosh: gdth combined patchset & call for testers. (October 1, 2007)

• Jeff Garzik: Broadcom and Marvell SAS/SATA drivers, draft 2. (October 2, 2007)

• Mauro Carvalho Chehab: videobuf tree. (October 2, 2007)

Documentation

• Michael Kerrisk: Revised signalfd man-page. (September 27, 2007)

• Michael Kerrisk: eventfd.2 man page. (September 27, 2007)

• Jeff Garzik: Document x86-64 iommu kernel parameters. (October 3, 2007)

• Peter Zijlstra: lockstat: documentation. (October 3, 2007)

Filesystems and block I/O

• NeilBrown: Change prototype for bi_end_io. (October 1, 2007)

• David Howells: Remove iget() and read_inode(). (October 1, 2007)

Janitorial

• Ahmed S. Darwish: Completely remove deprecated IRQ flags (SA_*). (October 1, 2007)

Kernel building

• Sam Ravnborg: Extending kbuild syntax. (October 1, 2007)

Memory management

• Mel Gorman: Use one zonelist per node instead of multiple zonelists v8. (October 1, 2007)

• Adam Litke: [PATCH 0/4] [hugetlb] Dynamic huge page pool resizing V6. (October 1, 2007)

Networking

• Herbert Xu: : Add stateless NAT. (October 1, 2007)

• Eric Dumazet: Make TCP prequeue configurable. (October 1, 2007)

• KOVACS Krisztian: Transparent Proxying Patches, Take 3. (October 1, 2007)

• KOVACS Krisztian: Transparent Proxying Patches, Take 4. (October 3, 2007)

• Urs Thuermann: CAN: Add new PF_CAN protocol family, try #9. (October 2, 2007)

Architecture-specific

• Nick Piggin: x86: improved memory barrier implementation. (October 1, 2007)

Security-related

• Casey Schaufler: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel. (October 1, 2007)

• Casey Schaufler: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel. (October 3, 2007)

• Serge E. Hallyn: capabilities: per-process capbset. (October 1, 2007)

• Kentaro Takeda: [TOMOYO 00/15](repost) TOMOYO Linux - MAC based on process invocation history.. (October 2, 2007)

Virtualization and containers

• Jeremy Fitzhardinge: [PATCH RFC] paravirt_ops: refactor struct paravirt_ops into smaller pv_*_ops. (October 1, 2007)

• Eric W. Biederman: net: Add network namespace clone & unshare support.. (October 1, 2007)

Miscellaneous

• Luis R. Rodriguez: New 'Changes-licensed-under' tag introduced for Linux-wireless. (September 28, 2007)

• Bradley M. Kuhn: ath5k: final correction of copyright notices. (October 1, 2007)

• Andrew Morton: -mm merge plans for 2.6.24. (October 1, 2007)

Page editor: Jonathan Corbet

Distributions

News and Editorials

Unofficial Fedora Spins

Multimedia support has been and will continue to be an issue in the free software world, at least in those countries that allow software patents. Many multimedia codecs are patented. There are many small Linux distributions that include multimedia codecs and they all tend to be hosted in Europe or elsewhere in the world where software patents are not recognized.

Fedora is a U.S. company and the U.S. does recognize software patents. Therefore Fedora does not play many multimedia files. We still have Ogg and FLAC providing free audio/video formats. However some people, many coming from the Windows world, expect their MP3s, and MPEG files to "just work" and they get frustrated when they find that these things are difficult. These codecs are not in the main Fedora repository, and never will be unless the U.S. suddenly reverses its decision on software patents (which doesn't seem likely).

The Fedora-devel list had a lengthy discussion this week about creating a Fedora spin with multimedia support out of the box. The poster, Jóhann Guðmundsson of Iceland, wondered if such a spin (hosted in Iceland) could be considered an official Fedora spin, and if not how much work would be involved.

Since Iceland is one of those European Union countries that currently does not recognize software patents, such a spin would be legal there. However, the official word, summarized in this post from Jesse Keating, is that official Fedora spins can only use the packages in the main Fedora repository. Otherwise they must be called something other than Fedora and must not contain any Fedora trademarks or official artwork.

For those who still think that creating the Fedora-based "MyBlueCap" distribution would be a good idea, here's some places to start. A new wiki page on creating custom spins has been recently created. It only addresses official spins, of course, but it's a start. The Fedora Trademark Guidelines will help you figure out if your spin crosses the line into unofficial territory. More guidelines on redistributing Fedora can be found here.

Changing the name of the project and replacing the artwork so that the new spin is no longer "Fedora" would seem to be a daunting task. But work is underway to make this easier. Feature generic logos are targeted for Fedora 8. According to the wiki page: "We want to enable generic branding for Fedora, such that a tree built without fedora-logos is still reasonably functional if done right, without excessive developer attention."

Even with the Feature Generic Logos, the creator of "MyBlueCap" still has much work to do. It is nice of Fedora to supply some logos, but ultimately the Fedora developers have plenty to do and should not be expected to divert their efforts towards making it easy to create unofficial derivatives with software that is not free everywhere.

Later on this page there is an interview with Clement Lefebvre, the creator of Linux Mint. Linux Mint (hosted in France) is making a Ubuntu derivative with all the multimedia codecs installed and ready to use.

Comments (4 posted)

New Releases

Fedora Unity releases updated Fedora 7 Re-Spins.

The Fedora Unity Project has announced the release of new ISO Re-Spins (DVD and CD Sets) of Fedora 7. These Re-Spin ISOs are based on Fedora 7 and all updates released as of September 12, 2007. The ISO images are available for i386 and x86_64 architectures via jigdo.

Full Story (comments: none)

Musix GNU+Linux 1.0 R3 Test1 released

Musix GNU+Linux 1.0 R3 test1 has been announced. "The Musix project has released the Musix GNU+Linux 1.0 R3 test1 Live-CD. This testing version was produced on the basis of the stable version 1.0 R2, based on Knoppix and Debian/Stable. Musix 1.0 R3 Test1 solves several problems, among them, the Inconsistent Filesystem Structure bug after an electrical shutdown. New functionalities were added, for instance: automount of CDs, DVDs and USB memories, or the "install" boot argument."

Full Story (comments: none)

Ubuntu 7.10 Beta released

A Beta release of Ubuntu 7.10 has been announced. "The Ubuntu team is proud to announce the beta release of Ubuntu 7.10 and its variants, Kubuntu, Edubuntu and Xubuntu. Codenamed "Gutsy Gibbon", 7.10 continues Ubuntu's proud tradition of integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution. Ubuntu 7.10 on the desktop features a cutting-edge graphical experience with composited desktop effects, fully automated printer installation, and superior support for Firefox browser plugins. Ubuntu 7.10 server edition brings enhanced security-in-depth with AppArmor and easy install-time options for multiple common server configurations."

Full Story (comments: 18)

Distribution News

openSUSE is looking for a Chief Linux Evangelist

The openSUSE project is looking for an enthusiastic Chief Evangelist to promote and spread the adoption of openSUSE, be a public face for the project on conferences and events, act as voice of the community back to Novell's leadership team, develop and nurture the openSUSE communities and pro-actively drive openSUSE marketing.

Full Story (comments: none)

[openSUSE] YaST Survey Started

openSUSE is running a survey on YaST. "If you use any of the distributions openSUSE, SUSE Linux, SUSE Linux Enterprise Desktop or SUSE Linux Enterprise Server, I encourage you to participate in our survey to support us improving YaST. The survey will be online until mid November and the results will be published on openSUSE.org."

Full Story (comments: none)

Fedora-fr association is born !

The French Fedora Team has announced the creation of the association of French speaking Fedora users. "Why an association ? * In order to promote Free software in general and the Fedora distribution in particular. This promotion will lead to the creation of support for the Fedora promotion, from simple flyers to CD/DVD for the installation of Fedora."

Full Story (comments: none)

Second Call for votes for Constitutional amendment: reduce the length of DPL election process

The second and final call for votes has gone out on a constitutional amendment to reduce the length of the Debian Project Leader election process.

Full Story (comments: none)

New Distributions

Kiwi Linux

Kiwi Linux is a modified Ubuntu live CD for the i386 architecture. It includes Romanian and Hungarian localization, multimedia codecs, encrypted DVD support, Flash and Java plugins for Firefox, PPPoE GUI for accessing local internet services (Clicknet and RDS) and write support for NTFS partitions. Kiwi uses the same software repositories as Ubuntu with one additional source added for the handful of artwork related or slightly modified packages. Kiwi has released the Kiwi 7.10 beta live CD.

Comments (2 posted)

Distribution Newsletters

Fedora Weekly News Issue 103

The Fedora Weekly News for September 24, 2007 has the following announcements: "Cast your vote for the Fedora 8 Codename", "Fedora Unity releases updated Fedora 7 Re-Spins", plus several other topics.

Full Story (comments: none)

Gentoo Weekly Newsletter

The Gentoo Weekly Newsletter for September 24, 2007 covers the Council election results, Sparc team seeking AT's, KDE Tips and Tricks, and several other topics.

Comments (none posted)

Full Circle Magazine #5

The September edition of Full Circle Magazine (The FREE Independent Magazine for the Ubuntu Linux Community) is available in PDF format. This issue contains Fluxbuntu - Step-by-step Install, How-To : Report Bugs with LaunchPad, CoLoCo Edubuntu Presentation, From VMware to VirtualBox and Learning Scribus Pt.5, Review of Bridge Construction Kit, Preview of Gusty Gibbon, and more.

Comments (none posted)

Ubuntu Weekly Newsletter #59

The Ubuntu Weekly Newsletter for September 29, 2007 covers the Ubuntu 7.10 Beta release, newly approved LoCo team and Ubuntu members, LoCos participating in Ohio LinuxFest 2007, and much more.

Full Story (comments: none)

DistroWatch Weekly, Issue 222

The DistroWatch Weekly for October 1, 2007 is out. "PC-BSD is fast becoming a highly usable alternative to Linux on the desktop and the project's latest release, version 1.4, is the most feature-full desktop FreeBSD ever. But can it stand tall against Linux? Read our review to find out. In the news section: openSUSE begins uploading the 10.3 CD images, Mandriva abandons its "Club" subscription service, Clement Lefebvre defends multimedia codecs in Linux Mint, Sabayon promises more bleeding-edge features in version 3.5, and Ubuntu closes on the upcoming "Gutsy Gibbon" release with a bunch of interesting new features. Finally, we are pleased to announce that the DistroWatch.com September 2007 donation goes to Damn Small Linux."

Comments (none posted)

Newsletters and articles of interest

Interview with Colin Walters about the online desktop

The Fedora project has an interview with Colin Walters about the GNOME online desktop and its status for Fedora 8. "The Big Board is a part of the Online Desktop effort; it's a new panel type component that is intended to display more relevant things to your online life than the traditional panel. You could think of it as a collection of custom "widgets" for things like Google Calendar or Docs, except we're less interested in some things that might spring to mind with the term widgets, such as gigantic meticulously rendered clocks."

Comments (11 posted)

Interview: Clement Lefebvre of Linux Mint by Tony Mobily (Free Software Daily)

Tony Mobily talks with Clement Lefebvre, lead developer of Linux Mint. "TM: Clement, first of all please introduce yourself to our readers! Where are you from? What do you do? CL: My name is Clement Lefebvre--people usually refer to me as "Clem"--and I'm the founder of the Linux Mint distribution. I maintain the Main and Light Editions and also develop most of the mint tools (mintDisk, mintInstall, mintUpload..etc). I'm 29 years old and I'm passionate about Linux. I'm from Paris, France. I studied Computer Sciences over there and got a Masters Degree in IT. That was in 2001. Since then I basically worked for different companies in France and in Ireland, as a J2EE trainer, as a Web developer, as a Software Engineer and (at the moment) as a Java developer."

Comments (none posted)

The Open CD forks to OpenDisc

The Open CD project has been moved to the new OpenDisc project, according to Gerald Stone's blog. "OpenDisc is a collection of high quality open source software for the Microsoft Windows platform, aimed at users exclusively using said operating system. The two goals of the disc are to provide free alternatives to otherwise costly equivalents, and to educate people about the Linux operating system." (Thanks to Jim Welch).

Comments (6 posted)

How things are going (in Sabayon Linux)

Fabio Erculiani writes about Gentoo-based Sabayon Linux. "Even if I prefer coding rather than blogging about Entropy these days (eheh, let me keep this kind of secrecy for now), I can't hide the fact that today has been a great day for the whole project. I successfully upgraded a 3.4F installation to the current available binary packages using Equo (that contain X.Org 7.3 for example...). A lot of code is still missing (like etc-update alike function, env-update, post/pre install scripts and so on), but things are moving fast!"

Comments (none posted)

Photo Gallery: Ubuntu Gutsy Gibbon 7.10 (TuxJournal)

TuxJournal.net has a short article (in Italian) with lots of screen shots covering the first beta of Ubuntu Gutsy Gibbon 7.10.

Comments (none posted)

Distribution reviews

openSUSE 10.3 RC 1 Report (TuxMachines)

TuxMachines.org looks at the first release candidate of openSUSE 10.3. "OpenSUSE 10.3 final is due out in just a few days, so let's take a look at the progress. Folks have been testing this release candidate and posting their thoughts here and there. My own testing was delayed primarily due to the some of the joys of running Gentoo fulltime, but I was finally able to devote my full attention to openSUSE 10.3 RC1. As per my usual, I downloaded the DVD iso delta. This time it was 422 MB. I don't usually test everything with these developmental releases, but what I have tested is looking good."

Comments (none posted)

Page editor: Rebecca Sobol

Development

Ardour 2, a first look

Ardour is a long running multi-track audio workstation project by Paul Davis and others. Davis is also the lead developer behind JACK, the Jack Audio Connection Kit, which allows multiple applications to share the same sound card.

Ardour can be contrasted with Audacity, a much simpler multi-track capable recording application that was examined in the LWN article Multi-track recording with Audacity.

Installation of Ardour is a complicated process. Your author decided to take the easy path to getting the application running by installing the current version of the Ubuntu Studio distribution. Ubuntu Studio comes with Ardour 2 rev 1762 and includes a Linux kernel with real-time support, JACK, and numerous other useful audio applications:

A multi-track soundcard is highly recommended for getting the most out of Ardour. The M-Audio Delta 44 card was selected. The system uses an Asus A7V 333 motherboard with an Athlon 1800 CPU and 512 MB of system RAM. The system has two hard drives, one for the operating system and another for storing the audio data. The system's video card is an ATI Radeon 8500. Ardour will function with a 1024x768 resolution video display, but a 1280x1024 or higher resolution display is highly recommended so that the main window and mixer windows can be viewed simultaneously.

An external mixing board adds a lot of flexibility to the recording setup, a Behringer Eurorack UB1202 was connected to the Delta 44 card to provide microphone preamplification, tone control and an effects loop. The UB1202 only provides two outputs, a four channel mixer would be a better choice for use with the Delta 44. The first two channels from the Delta 44 were connected to a stereo's aux inputs to allow high fidelity monitoring of the audio.

These screenshots show the Ardour main window, mixer application and the qjackctl GUI interface to JACK.

With this system, Ardour 2 is able to do basic sound-on-sound recordings. Two primary tracks can be recorded, two more tracks can be added while listening to the first tracks, and more tracks can be added later. The Ardour user interface is fairly intuitive, it did not take long to figure out how to record tracks, add new tracks, extend existing tracks and zoom in and out with the audio waveform display. A nice feature is the automatic highlighting of clipped audio samples with red dots on the waveform display. Ardour takes a while to master, but that is to be expected is an application that takes on such a complicated list of tasks. Ardour has a good online manual that is helpful for learning the application.

Initially, it seemed that the system's hardware was not quite up to the task of running Ardour reliably. While playing previously recorded material, moving the mouse between windows on the screen caused small, but highly annoying clicks in the audio stream. Moving the mouse while recording resulted in clicks on the recorded tracks, badness 10,000. Adding another 256MB of RAM to the system did not change the behavior, the top utility supported this by showing 0MB of swap in use with the 512MB memory configuration. Switching to an Athlon 2200 processor reduced the clicking somewhat, but the problem was still present.

After much poking and prodding, the problem was eventually traced to JACK not being configured for realtime operation by default. The fix was easy, it involved clicking on the qjackctl setup button, selecting the realtime button, and restarting everything. No more obnoxious clicking.

Ardour's recorded audio quality using the Delta 44 sound card is quite good. In boutique audio lingo, you can hear lots of subtle nuances in the sound and the hiss is minimal. Ardour 2 shows many improvements over earlier versions, it is truly a nice application. Ubuntu Studio is also a huge step forward. It is possible to go from a blank box to a system with a functioning multi-track recorder in under an hour by answering a small number of installation questions and waiting for the installation to complete.

Comments (6 posted)

System Applications

Backup Software

Areca Backup 5.3.5 is available (SourceForge)

Version 5.3.5 of Areca Backup has been announced. "Areca Backup is a file backup tool written in java. It supports data compression & encryption, incremental backup, file history explorer and many other features. Areca Backup also includes a transaction mechanism which guarantees your backups' integrity. This new version includes : Some mail report enhancements, A file permission recovery bug fix".

Comments (none posted)

Database Software

Firebird 2.0.3 released

Sub-release 2.0.3 of the Firebird RDBMS has been announced. "This sub-release does not add any new functionality to the database engine. It contains a number of fixes to bugs discovered since the v.2.0.1 sub-release and corrects a regression that caused the withdrawal of the v.2.0.2 sub-release. Minor improvements include a port of Firebird 2.0.3 Classic for MacOSX on Intel and increased access security for the Firebird log."

Comments (none posted)

MySQL 5.1.22-rc has been released

Version 5.1.22-rc of the MySQL DBMS is available, it adds a new innodb_autoinc_lock_mode system variable and a large number of bug fixes. "we are proud to present to you the MySQL Server 5.1.22-rc release, the first 5.1 "release candidate" version of the popular open source database. Bear in mind that this is still a "candidate" release, and as with any other pre-production release, caution should be taken when installing on production level systems or systems with critical data."

Full Story (comments: none)

PostgreSQL Weekly News

The September 30, 2007 edition of the PostgreSQL Weekly News is online with the latest PostgreSQL DBMS articles and resources.

Full Story (comments: none)

Embedded Systems

BusyBox 1.7.2 announced

Version 1.7.2 of BusyBox, a collection of command line tools for embedded systems, has been announced. "This is a bugfix-only release, with fixes to install, find, login, httpd, runsvdir, chcon, setfiles, fdisk and line editing."

Comments (none posted)

Interoperability

First preview of Samba 3.2.0 announced

The first preview release of Samba 3.2.0 has been announced. "This is the first preview release of Samba 3.2.0. This is *not* intended for production environments and is designed for testing purposes only."

Full Story (comments: none)

Printing

CUPS 1.3.3 released

Version 1.3.3 of CUPS, the Common Unix Print System, has been announced. "CUPS 1.3.3 is now available for download from the CUPS web site and fixes some scheduler and localization issues."

Comments (none posted)

Security

pam_mount 0.29 released (SourceForge)

Version 0.29 of pam_mount has been announced "pam_mount is a Pluggable Authentication Module that can mount volumes for a user session. Supports any filesystem your kernel is capable of, including tmpfs, FUSE, smbfs, cryptoloop, LUKS mounts, --bind and more. An uninitialized array and a copy-and-paste error were corrected in the recently introduced process spawn code."

Comments (none posted)

Miscellaneous

Linux-ready Firmware Developer Kit release 3

The third release of the Linux-ready Firmware Developer Kit is available. Some new test kernels have been added, the documentation has been improved, and a number of other enhancements have been made; click below for the details.

Full Story (comments: none)

Desktop Applications

Desktop Environments

Compiz 0.6.0 announced

Version 0.6.0 of Compiz, a 3D window manager, is out with an incredibly long list of improvements and bug fixes. Here are a few of the changes: "Better support for multiple X-screens. XML-based meta-data system for handling of various kinds for meta-data like plugin descriptions, default option values, etc. Major improvements to option initialization based on the new meta-data system. Extensible logging framework. Plugin plugins that make it possible to adjust and extend the behavior of existing plugins through new plugins. More dynamic handling of output devices, which allows the output device configuration used when rendering to be changed between frames."

Full Story (comments: none)

GNOME Software Announcements

The following new GNOME software has been announced this week:

• Conduit 0.3.4 (new features and bug fixes)
• Empathy 0.13 (new features and bug fixes)
• gcalctool 5.20.1 (bug fix and translation work)
• gedit-plugins 2.20.0 (new features, bug fixes and translation work)
• gnome-control-center 2.20.0.1 (bug fixes and translation work)
• gtk-doc 1.9 (new features and bug fixes)
• gtkmm-utils 0.2.1 (build fix)
• Hipo 0.5 (new features, bug fixes and translation work)
• iogrind 0.0.1 (initial release)
• MonoDevelop 1.0 beta 1 (new features and bug fixes)
• PyGTK 2.12.0 (new features)
• Tracker 0.6.3 (new features, bug fixes and translation work)

You can find more new GNOME software releases at gnomefiles.org.

Comments (none posted)

KDE Software Announcements

The following new KDE software has been announced this week:

• Amarok Atom Syndication 0.1.2 (unspecified)
• aMule kollection 0.2 (new features and installation improvements)
• eric4 4.0.2 (bug fixes)
• eric4 4.0.3 (bug fixes)
• KBarcode 2.0.6 (bug fix)
• KCheckGMail 0.5.7.2 (bug fixes and translation work)
• KDE Priority handler 0.2 Beta (new features and bug fixes)
• KGtk 0.9.1 (build system change and bug fixes)
• Kisa 0.32 (initial release)
• KMPlayer 0.10.0 (new features and bug fixes)
• Konversation Auto-replaces 0.0.1 (initial release)
• kputsite 0.1 (code cleanup)
• kReiSSy 0.1.1 (unspecified)
• KSniffer 0.3.1 (bug fixes and performance improvements)
• nmapsi4 0.0svn01 (unspecified)
• QBrew 0.4.0 (new features and bug fixes)
• QTGZManager Beta3 (new features and bug fixes)
• Transforme-me 0.1.2 (new features and bug fixes)
• Transforme-me 0.3 (bug fixes)
• Yakuake 2.8 (new features and bug fixes)
• Zhu3D 3.0.4 (new features, bug fixes and performance improvements)

You can find more new KDE software releases at kde-apps.org.

Comments (none posted)

Xorg Software Announcements

The following new Xorg software has been announced this week:

• xf86-video-ati 6.7.194 (new features and bug fixes)
• xf86-input-vmmouse 12.4.3 (bug fix)
• xf86-video-mga 1.9.100 (bug fixes and code cleanup)
• xf86-video-vmware 10.15.2 (bug fix)
• xfs 1.0.5 (new feature and bug fixes)

More information can be found on the X.Org Foundation wiki.

Comments (none posted)

Financial Applications

LedgerSMB 1.2.8 Released

Version 1.2.8 of the LedgerSMB accounting package is out. Given that this release "corrects a number of security and accounting logic issues," most users will probably want to do the upgrade. In particular, it appears that there is a set of SQL injection vulnerabilities in previous releases.

Full Story (comments: none)

GUI Packages

pyFltk2 1.0.0b1 announced

Version 1.0.0b1 of pyFltk2, a Python language binding for the FLTK2 toolkit, has been announced. "The first beta release of the Python bindings for FLTK2 is available for download from Sourceforge: http://pyfltk.sourceforge.net. This release supports and has been tested with fltk-2.0-r5940."

Comments (none posted)

wxWidgets 2.8.6 released

Version 2.8.6 of the wxWidgets GUI toolkit has been announced, it is mainly a bug fix release. "October 1st, 2007 -- the wxWidgets team is pleased to announce a new wxWidgets release. wxWidgets is a mature, open source, cross-platform application framework for C++ and other languages."

Comments (none posted)

Interoperability

Wine 0.9.46 announced

Version 0.9.46 of Wine has been announced. Changes include: A variety of fixes to improve Photoshop CS2 support, More complete support for device installation in setupapi, New Bidi text implementation that doesn't depend on libicu, The usual assortment of Direct3D improvements, Beginning of I/O completion ports support and Lots of bug fixes.

Comments (none posted)

Mail Clients

Claws Mail 3.0.2 released

Version 3.0.2 of Claws Mail, a light weight GTK+ email client, has been announced, it features a number of bug fixes.

Comments (none posted)

Medical Applications

PatientOS version 0.12 released (LinuxMedNews)

Version 0.12 of PatientOS has been announced. "PatientOS is an open source healthcare information system physicians, nursing, pharmacy, laboratory and ultimately all departments in a hospital, physician practice, or any other healthcare facility. Version 0.12 adds the foundation code to support the creation and maintenance of a formulary. Pharmacists can create medications, and associate rules for dose checking. Medications may be created defining dose and dispense details to build the formulary."

Comments (none posted)

Office Applications

HylaFAX 4.4.2/4.3.6 releases

Versions 4.4.2 and 4.3.6 of HylaFAX, a FAX modem interface application, has been announced. "These releases are maintenance releases, and do not contain any new features or functionality, but only contain bugfixes".

Comments (none posted)

Office Suites

Meeks on OpenOffice.org

Worth a read: this weblog entry by Michael Meeks on Sun's management of OpenOffice.org. "If OpenOffice was blessed (like other more sensibly structured projects) with a large, diverse and healthy developer-base, then perhaps we could expect to go around rejecting big chunks of code, offending developers and driving away potential contributors. To do this solely in order for Sun to retain total ownership of the code-base (and even loosely coupled components) - seems rather a betrayal of it's self-appointed stewardship role..." Many company-driven projects require transfer of copyright ownership from contributors, so OOo is not the only place issues like this will come up. (See also: this discussion of ooo-build from 2004. ooo-build was not a full fork of OpenOffice.org then and does not appear to be one now.)

Comments (48 posted)

OpenOffice.org Newsletter

The September, 2007 edition of the OpenOffice.org Newsletter is out with the latest OO.o office suite articles and events.

Full Story (comments: none)

Languages and Tools

Caml

Caml Weekly News

The October 2, 2007 edition of the Caml Weekly News is out with new Caml language articles.

Full Story (comments: none)

Java

Joda-Time Hibernate support 1.0 (SourceForge)

Version 1.0 of hibernate support for Joda-Time has been announced. "Joda-Time provides a library of classes to replace the Java JDK Date and Time classes including formatting. It is based around the ISO8601 datetime standard, but also provides full support for other calendar systems, such as Gregorian and Buddhist. The new release of hibernate support for Joda-Time is now available. This supports persisting LocalDate, LocalTime, LocalDateTime, Period and Duration."

Comments (none posted)

Lisp

SBCL 1.0.10 has been released

Version 1.0.10 of Steel Bank Common Lisp has been announced. "This version improves environment access, speeds up CLOS slot accesses, and fixes some bugs. SBCL is a native compiling Common Lisp implementation, under MIT/Public Domain licence. It purports to conform to the ANSI Common Lisp standard, and features several non-standard extensions."

Full Story (comments: none)

Python

Python-URL! - weekly Python news and links

The October 1, 2007 edition of the Python-URL! is online with a new collection of Python article links.

Full Story (comments: none)

Tcl/Tk

TclOO 0.1 released (SourceForge)

Version 0.1 of TclOO has been announced. "Donal Fellows is pleased to announce the release of version 0.1 of the TclOO package. This package (which requires Tcl 8.5b1 to work) provides an advanced high-speed Object Oriented system core for the Tcl programming language."

Comments (none posted)

Page editor: Forrest Cook

Linux in the news

Recommended Reading

Why GPLv3 Will Supplant GPLv2 (Linux Journal)

Glyn Moody muses on GPLv3 adoption in a Linux Journal article. He looks at the history of licensing and concludes that GPLv3 adoption is inevitable. "The interesting point here is that it was not legal issues that prompted the adoption of the GPL, but simply a desire to make it easier for MySQL to be included in distributions by simplifying the legal wrapping. MySQL is not alone in making the move to the GNU GPL for this reason."

Comments (none posted)

Finland's Summer Coders to Open their Minds (by Paul Sladen)

Paul Sladen covers [click below] the Finnish Summer of Code. "Google's Summer of Code may have taken the limelight, but in the north-east corner of Europe there has been another smaller (near) namesake taking place. Since 2006, Finland has had its very own Summer of Code—"Kesäkoodi", "summer code" in Finnish—organised and backed with the help of Finnish companies wanting to contribute to the community at a local level."

Full Story (comments: 1)

Trade Shows and Conferences

HP: Linux ready for mission-critical applications (ZDNet UK)

HP's Randy Hergett speaks at the Gelato Itanium Conference & Expo in Singapore. ""[Linux] is ready for most applications," he said, noting that there are telecommunications companies running mission-critical databases on Linux, and overall adoption levels are ramping up."

Comments (4 posted)

Announcing the KDE 4.0 Release Event (KDE.News)

KDE.News looks forward to the KDE 4.0 release media event, happening January 17 to 19 in Mountain View, California. "There will be plenty of time and opportunity for interaction between all attendees; but there will also be many interesting presentations, involving both technical and non-technical topics. We have invited over 200 members of the media, I.T. business, distributions and other Free Software groups, completed of course with many members from the North-American KDE community. Further, several international KDE hackers will attend to give talks or help organise the event."

Comments (none posted)

Companies

Red Hat Rises After New Linux Products Fuel Sales (Bloomberg)

Bloomberg covers the latest financial results from Red Hat, Inc. "Red Hat's Enterprise Linux 5 software, released in March, sold faster than expected last quarter, increasing cash flow. The Raleigh, North Carolina-based company also persuaded existing customers to use Red Hat software on more of their computers. ``Cash flow from operations was very solid compared to last quarter, and the revenue beat expectations,'' said Denny Fish, an analyst at JMP Securities in San Francisco. He has a ``market perform'' rating on the stock. Cash flow from operations rose 43 percent to $63.7 million last quarter from a year earlier. In the previous quarter, it declined 4 percent."

Comments (3 posted)

Red Hat faces stiff challenges to move beyond its core technology (LinuxWorld)

John Fontana writes about Red Hat. ""The big challenge for Red Hat is moving from an [operating system] distributor to becoming a distributor of an application platform, a virtualization platform, an SOA platform. Moving into those spaces is not an easy transition," says Denny Fish, senior analyst for infrastructure software and services for financial services firm JMP Securities. "They are selling to different people within an organization. The [operating system] is often an indirect sale, but with the middleware platform, for instance, you are selling to application developers and systems architects.""

Comments (none posted)

Linux Adoption

Kubuntu Takes Over the Canary Islands (Ubuntu Fridge)

The Ubuntu Fridge team reports that Kubuntu in taking over the Canary Islands. "The Canary Islands have two derivatives of Kubuntu, one which is being installed in all their schools and one used by the largest university. The Jornadas de Software Libre conference at The University of La Laguna, took place in Tenerife, Canary Islands, Spain, from the 18th-21st September 2007. It was organised by the university's Software Libre Office (OSL)." (Found on KDE.News)

Comments (none posted)

Legal

Microsoft, antitrust and innovation, by Georg Greve (Groklaw)

Free Software Foundation Europe president Georg Greve discusses the fallout from the recent EC antitrust ruling against Microsoft. "If one were to believe Microsoft, antitrust law is for sore losers who are too lazy to innovate, and the decision of the European Court of Justice against Microsoft was to the detriment of consumers around the world. One might even believe that any company with large enough market share would now have to fear the wrath of the European Commission and its anti-innovation bloodhounds. At first the notion seemed ludicrous, but then more and more blogs repeated it and serious media started picking it up. Even representatives of the US government spoke out on behalf of Microsoft, to the annoyance of Neelie Kroes, the European Union's antitrust commissioner."

Comments (1 posted)

Interviews

Community interview: Novell answers 10 questions (BR-Linux.org)

BR-Linux.org presents a community interview with Novell, here's a summary of the responses: "One of the questions, sent by the reader semente, wasn't answered at all, other answers look evasive, some of them repeat known company policy without adding much more meat to it (the deal was about interoperability, you know), but most of them may reveal more than a glimpse of unfiltered opinion: “Novell believes there should be one open standard and that standard is ODF”, “We do not believe that Linux infringes on any Microsoft patents”, “We welcome GPLv3”, and so forth." (Thanks to Augusto Campos).

Comments (6 posted)

An Interview with ECIS's Thomas Vinje on the EU Microsoft Decision, by Sean Daly (Groklaw)

Sean Daly talks with Thomas Vinje about the EU Microsoft Decision and OOXML. "When the EU Court of First Instance announced its verdict on September 17, upholding the EU Commission's findings that Microsoft abused its market dominance, the media flocked to the lawyers representing the various parties for reactions to the ruling, Brad Smith for Microsoft, Carlo Piana for FSFE and Samba, and Thomas Vinje, who represented ECIS, the European Committee for Interoperable Systems."

Comments (none posted)

Resources

Linux Gazette #143

The October 2007 edition of Linux Gazette is out. Articles in this issue include An Ongoing Discussion of Open Source Licensing Issues, Linux Console Scrollback, Securing Apache Web Server with mod_security, Introducing Python Pickling, and more.

Comments (none posted)

Loop-based Music Composition With Linux, Pt. 2 (Linux Journal)

In this Linux Journal article, Dave Phillips completes his look at using Linux for loop-based composition. He looks at Ardour, Reaper, and Audacity to create and edit music from sampled sources. "Drummers are pattern-playing creatures, but to keep things interesting they vary those patterns from time to time. We can liven up our example by replacing every fourth loop with a variation of the groove or a fill taken from the same source loop collection. Simply load the new set of audio files as new tracks, edit as desired, then mix and match until you find the right combination of patterns (i.e. what pleases your ears)."

Comments (none posted)

High-performance network programming, Part 1 (developerWorks)

IBM developerWorks looks at squeezing the maximum usage out of your network resources. "Though bandwidth available to a particular protocol is limited by Shannon's law and other factors, such as network usage patterns, most of the time it is shoddy programming or naive coding that causes suboptimal utilization of network resources. Performance enhancement is also an art as much as it is a science. To get the best end-to-end throughput, you have to employ various tools to measure performance, identify bottlenecks, and eliminate them or minimize their impact. You can quickly get a huge performance boost by simple and straightforward scientific methods."

Comments (17 posted)

Reviews

GNOME 2.22 planning: Empathy messaging client and toolkit proposed for inclusion (ArsTechnica)

ArsTechnica looks at the instant messaging client Empathy, which has been proposed for inclusion in GNOME 2.22. "Empathy is rapidly becoming an important part of the GNOME software ecosystem and is already packaged in several mainstream distributions, including the upcoming Ubuntu 7.10 release. Empathy integration features for Nautilus, Totem, Epiphany, and Jokosher and others are currently being developed. The Empathy toolkit is also being used by Intel as part of its new Linux-based mobile platform. Telepathy could eventually provide pervasive messaging and presence functionality throughout the entire desktop environment." (Found on GnomeDesktop)

Comments (3 posted)

The Mono Project: You Might Expect the Unexpected (Linux Journal)

Tom Adelstein looks at the Mono project. "Back in February, Ralph Green asked me to speak at the North Texas Linux Users' Group. I discussed Linux administration and then took questions. Some one in the audience asked me about Mono. I gave a cavalier answer having a bias against it. Then someone else in the audience said that I needed to get my facts straight."

Comments (42 posted)

Miscellaneous

To Sir, with Love: How To Get More Women Involved in Open Source (O'ReillyNet)

In this article from O'Reilly's Women in Technology series Selena Deckelmann shares some suggestions for how to get more women involved in open source. "We can learn from research about increasing diversity. I'm sure smart people have summarized, put together lists of bullet points, and made handbooks to show how to do it. Certainly, organizations dedicated to fixing inequalities will be touchstones for change. But we need more than leadership to change our culture. We each can take steps now to make women feel like there is a place for them in our communities."

Comments (205 posted)

Page editor: Forrest Cook

Announcements

Non-Commercial announcements

EFF: Justice Department Withholds Records of Stealth Campaign to Block Surveillance Suits

The Electronic Frontier Foundation has announced the filing of a lawsuit against the U.S. Department of Justice. "The Electronic Frontier Foundation (EFF) filed suit against the Department of Justice (DOJ) today, demanding any records of a telecom industry lobbying campaign to block lawsuits over their compliance with illegal electronic surveillance. EFF's lawsuit comes as Congress debates letting telecommunications companies off scot-free as part of the hotly disputed "modernization" of the Foreign Intelligence Surveillance Act (FISA). EFF represents the plaintiffs in Hepting v. AT&T, a class-action lawsuit brought by AT&T customers accusing the telecommunications company of violating their rights by illegally assisting the National Security Agency in domestic surveillance."

Full Story (comments: none)

Linux Foundation Technical Advisory Board Election Results

James Bottomley has announced the results of the election for members of the Linux Foundation Technical Advisory Board which was held on September 5th at the kernel summit. Five people were elected: Arjan van de Ven, Greg Kroah-Hartman, Christoph Lameter, Olaf Kirch, and LWN's own Jonathan Corbet. The first three listed were re-elected to the board, while Olaf Kirch and Jonathan Corbet are new. Click below for a bit more information on the election.

Full Story (comments: 3)

Linux Foundation teams up with Japanese government

The Linux Foundation has signed a collaboration agreement with the Information-technology Promotion Agency of the Japanese government. The agreement is targeted at increasing participation of Japanese developers in Linux and open source software. "This announcement comes during a time of heightened interest in open source use in Japan. Recent examples include the increasing use of Linux in consumer electronics devices manufactured in Japan and the Tokyo Stock Exchange's decision to use Linux for its next generation enterprise system. In July 2007, the Japanese government made open standards adoption a priority for all government IT procurements. The government has stated it has budgeted JPY1.25 trillion, or US $10.4 billion, on IT spending over the next year and will also develop a Linux-based system for its legal registration system."

Comments (none posted)

Yet another ath5k pronouncement from the SFLC

The attempt to create a Linux driver for Atheros-based wireless adapters would appear to be enough to keep the Software Freedom Law Center in business all by itself. The SFLC has announced the availability of a new document on the provenance and copyright status of the Linux ath5k driver. "Ultimately, all the copyright holders of the Linux ath5k-driver code, derived from ar5k, have been contacted and have agreed to license their changes under the ISC license, thus allowing improvements to be re-incorporated into OpenBSD. One of the three historical branches of the code reviewed by SFLC, however, included portions that are only licensed under the GPL, and SFLC has determined that it would be very difficult to re-incorporate that code into OpenBSD." The full report is available on the SFLC web site.

Comments (2 posted)

Commercial announcements

Announcing CrossOver 6.2 for Linux and Mac

Version 6.2 of CrossOver Linux and CrossOver Mac have been announced. "Version 6.2 supports the upcoming Team Fortress 2 release from Valve software, right out of the Orange Box, as it were. This adds to our growing list of games that work well in CrossOver. We feel that CrossOver is now a viable way to play popular games on Linux and on the Mac. It also includes some major work on Outlook, particularly for use in corporate environments, along with a range of bug fixes for many other applications."

Full Story (comments: none)

Levanta 6.0 brings automation capabilities to Linux-based data centers

Levanta has announced a family of data center automation solutions for growing Linux environments. "Levanta 6.0 delivers fully-integrated system and application monitoring and policy-driven automation of Linux system management functions in easy to deploy appliances, resulting in significantly lower cost and shorter implementation time."

Full Story (comments: none)

Mexico's largest mortgage lender chooses Novell for key business system

Novell, Inc. has announced a new deal with Mexico's Fondo Nacional de la Vivienda. "The Instituto del Fondo Nacional de la Vivienda (INFONAVIT), Mexico's largest mortgage lender, has tapped SUSE(R) Linux Enterprise from Novell(R) as its platform for customer transactions. Providing services to more than 12 million people and 830,000 employers, INFONAVIT has deployed SUSE Linux Enterprise as the basis for its new payment collection system. With SUSE Linux Enterprise Server, INFONAVIT has a stable, flexible platform that enables it to provide a high-quality, easy to use service, while streamlining costs and administrative processes."

Comments (none posted)

Open Kernel Labs Delivers OKL4 for OpenMoko Smart Phone

Open Kernel Labs has announced the availability of the OKL4 advanced open source microkernel architecture. "Open Kernel Labs (OK), a global provider of embedded systems software and virtualization technology, announces the availability of OKL4 for FIC's OpenMoko Neo1973 smart phone and the FancyPants advanced GUI platform from Fluffy Spider Technologies (FST). The products will be demoed at the upcoming ARM Developers Conference (Booth 511)."

Full Story (comments: none)

OpenVZ virtualization software available with CentOS Live CD

OpenVZ is now available on the CentOS Live CD. "The OpenVZ project today announced availability of its operating system (OS) server virtualization software as a modified version of the CentOS 4.4 bootable Live CD so that users can test drive the OpenVZ software without changes to their computer or installing anything on their hard disk. "We're following on the success of our delivery of a Live CD for the Knoppix distribution, which is very popular with hobbyists," said Kir Kolyshkin, manager of the OpenVZ project."

Full Story (comments: none)

xTuple announces PostBooks 2.2.1

xTuple has announced the release of Version 2.2.1 of its PostBooks Accounting, Enterprise Resource Planning (ERP), and Customer Relationship Management (CRM) solution. "The release is a follow-up to the recent version 2.2.0, and offers the open source community a new data import and mapping tool called CSVimp, as well as enhanced documentation and examples supporting the new xTuple Application Programming Interface (API) for connecting to external systems. The release also contains bug fixes and features suggested and contributed by the xTuple community."

Full Story (comments: none)

New Books

Making Things Talk--New from Make

Maker Media has published the book Making Things Talk by Tom Igoe.

Full Story (comments: none)

Security Data Visualization--New from No Starch Press

No Starch Press has published the book Security Data Visualization by Gregory Conti.

Full Story (comments: none)

Calls for Presentations

FOSS.IN and OpenOffice.org CFP

A call for papers has gone out for FOSS.IN. The event will take place in Bangalore, India on December 4-8, 2007. Submissions are due by October 8.

Full Story (comments: none)

LAC2008 Call for Papers, Music, etc.

A call for papers and materials has gone out for the 2008 Linux Audio Conference. The event will be held in Cologne, Germany on February 28 through March 2, 2008. Submissions are due by December 1.

Full Story (comments: none)

MySQL Conference and Expo 2008 CFP

The 2008 MySQL Conference and Expo will be held on April 15-18, 2008 in Santa Clara, California. "The event is expected to bring over 1,600 open source and database users together to harness the power of MySQL and celebrate the active MySQL ecosystem. The call for participation is now open for prospective speakers; submissions will be accepted until October 30, 2007."

Full Story (comments: none)

Upcoming Events

Akademy 2008 to be Held in Belgium (KDE.News)

KDE.News has posted an early announcement for the 2008 Akademy conference. "The annual KDE World Summit, Akademy, has found a home for 2008 in the heart of Europe, Belgium. The event is the most important conference for the contributors of the KDE project and will be held from Saturday August 9th to Saturday 16th at the De Nayer Institute, an associated campus of the University of Leuven. There are three sub-events: a contributors conference, the KDE e.V. annual general assembly and a week long hacking session."

Comments (none posted)

GNOME Boston Summit 2007

The GNOME Boston Summit will take place on October 6-8, 2007 in Boston, MA. "The Boston Summit is a three-day hackfest for GNOME developers and contributors. It is not primarily aimed at users or new contributors, but if you want to jump right into the deep end, it's a fantastic way to meet everyone and get involved. Unlike traditional conferences, the Boston Summit is all about getting developers together and getting things done. While there are some non-hacking sessions, they are geared heavily towards many-to-many, interactive discussion and planning, rather than one-to-many presentations."

Full Story (comments: none)

SugarCRM begins global CRM Acceleration world tour

SugarCRM has announced new dates and locations around the world for the CRM Acceleration Summit Series. Click below for a list of dates and places.

Full Story (comments: none)

Events: October 11, 2007 to December 10, 2007

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
October 10 October 12	Plone Conference 2007	Naples, Italy
October 12	Legal Summit for Software Freedom	New York, NY, USA
October 13 October 14	T-DOSE 2007 (Technical Dutch Open Source Event)	Eindhoven, The Netherlands
October 13	The Ontario Linux Fest Conference	Toronto, Canada
October 13	Aka Linux Kernel Developer Conference	Beijing, China
October 16	Databases and the Web	London, England
October 17 October 19	2007 WebGUI Users Conference	Madison, WI, USA
October 17 October 19	Web 2.0 Summit	San Francisco, CA, USA
October 18 October 20	HackLu 2007	Kirchberg, Luxembourg
October 19 October 21	ToorCon 9	San Diego, CA, USA
October 20 October 21	Ubucon.de	Krefeld (Köln), Germany
October 20	PostgreSQL Conference Fall 2007	Portland, OR, USA
October 20	./freedom & opensource day - PERU	Lima, PERU
October 21 October 25	OOPSLA 2007	Montreal, Canada
October 21 October 26	Colorado Software Summit	Keystone, CO, USA
October 22 October 26	OpenGL Bootcamp with Rocco Bowling	Atlanta, GA, USA
October 22 October 23	She's Geeky - A Women's Tech (un)Conference	Mountain View, CA, USA
October 23 October 25	Open aLANtejo 07 - CNSL07	Évora, Portugal
October 23 October 26	Black Hat Japan	Tokyo, Japan
October 25 October 26	FSOSS 2007 - Free Software and Open Source Symposium	Toronto, Canada
October 27 October 28	FOSSCamp 2007	Cambridge, MA, USA
October 27	Linux Day Italy	many cities around country, Italy
October 28 November 2	Ubuntu Developer Summit	Cambridge, Massachusetts, USA
October 29	3rd International Workshop on Storage Security and Survivability	Alexandria, VA, USA
October 29 November 1	Fall VON Conference and Expo	Boston, MA, USA
October 30 October 31	BCS'07	Jakarta, Indonesia
October 31 November 1	LinuxWorld Conference & Expo	Utrecht, Netherlands
November 1 November 2	The Linux Foundation Japan Symposium	Tokyo, Japan
November 2	5th ACM Workshop on Recurring Malcode	Alexandria, VA, USA
November 2 November 3	Embedded Linux Conference, Europe	Linz, Austria
November 2 November 4	Real-Time Linux Workshop	Linz, Austria
November 3	Linux-Info-Tag Dresden	Dresden, Germany
November 5 November 9	Python Bootcamp with Dave Beazley	Atlanta, USA
November 7	NLUUG 25th anniversary conference	Beurs van Berlage, Amsterdam, The Netherlands
November 7	Alfresco North American Community Conference 2007	New York, NY, USA
November 8 November 9	Blog World Expo	Las Vegas, NV, USA
November 10 November 11	Linuxtage	Essen, NRW, Germany
November 11 November 17	Large Installation System Administration Conference	Dallas, TX, USA
November 12 November 16	Ruby on Rails Bootcamp with Charles B. Quinn	Atlanta, USA
November 12 November 15	OWASP & WASC AppSec 2007 Conference	San Jose, USA
November 12 November 16	ApacheCon US 2007	Atlanta, GA, USA
November 13 November 14	IV Latin American Free Software Conference	Foz do Iguacu, Brazil
November 15 November 18	Piksel07	Bergen, Norway
November 15	Alfresco European Community Conference	Paris, France
November 16 November 18	aKademy-es 2007	Zaragoza, Spain
November 20 November 23	DeepSec ISDC 2007	Vienna, Austria
November 22 November 23	Conferencia Rails Hispana	Madrid, Spain
November 24	LinuxDay in Vorarlberg (Deutschland, Schweiz, Liechtenstein und Österreich)	Dornbirn, Austria
November 26 November 29	Open Source Developers' Conference	Brisbane, Australia
November 28 November 30	Mono Summit 2007	Madrid, Spain
November 29 November 30	PacSec 2007	Tokyo, Japan
December 1	Django Worldwide Sprint	Online, World
December 1	London Perl Workshop 2007	London, UK
December 4 December 8	FOSS.IN 2007	Bangalore, India
December 7 December 8	Free Software Conference Scandinavia	Gotherburg, Sweden
December 7 December 8	PGCon Brazil	Sao Paulo, Brazil

If your event does not appear here, please tell us about it.

Audio and Video programs

LinuxWorld video: Greg K-H on the Linux Driver Project

Online video is available from the May, 2007 FreedomHEC conference.

Full Story (comments: none)

Page editor: Forrest Cook