2

I am about to install a patch for wireless drivers named Compat Wireless in order to solve a problem with my WiFi channel (it locks on the not existing -1 channel) on my Ubuntu Linux v12.04 and Kali Linux v1.0.9.

But first I would like to know if this patch is already installed (why installing something I do have?).

I have done some research about, and I can not find a way to know if my patch is already there, nor a generic method to list installed patches. I don't even know if it is possible or not to obtain such info from a running Linux.

Any ideas, please?

4
  • sudo rpm -qa|grep compat that is how to do that on red hat, probably some way to do it on Ubuntu for the rpm equivalent
    – jgr208
    Commented Oct 18, 2014 at 23:16
  • Thanks, @jgr208, I have installed rpm on Kali, and your command yields no results. As long as I don't know if that means not installed or method not valid, I will wait for another confirmation about it. Commented Oct 18, 2014 at 23:42
  • That is top check what packages are installed, see what packages provides that patch and then grep that.
    – jgr208
    Commented Oct 18, 2014 at 23:43
  • Also on Red Hat based distros that make use of YUM you can use the CVE plugin: check if latest openssh patch provided by RHEL is installed
    – slm
    Commented Oct 19, 2014 at 0:11

3 Answers 3

6

Has a patch already been applied to my Linux kernel?

If one is comfortable enough with Linux to be applying a patch, as this questioner appears to be, then checking if the patch is already in the default kernel is relatively simple: Just check the source code.

Use the Source, Luke!¹

The following should work for any distribution derived from Debian GNU/Linux, which includes what the questioner asked for, Ubuntu:

apt source linux

That will download the Linux source and patch it to be exactly the same state as the distribution used when they compiled it. In the linux-x.y.z directory are the file(s) mentioned in the patch. Just look at the line numbers and make sure that the lines with minus signs aren't there and the ones with plus signs are. That's it.

More detailed answer

Patches are text files that look like this:

Signed-off-by: Alexey Brodkin <[email protected]>
---
 drivers/usb/core/urb.c | 5 -----
 1 file changed, 5 deletions(-)

--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -321,9 +321,6 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb);
  */
 int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
 {
-   static int          pipetypes[4] = {
-       PIPE_CONTROL, PIPE_ISOCHRONOUS, PIPE_BULK, PIPE_INTERRUPT
-   };
    int             xfertype, max;
    struct usb_device       *dev;
    struct usb_host_endpoint    *ep;
@@ -441,11 +438,6 @@ int usb_submit_urb(struct urb *urb, gfp_
     * cause problems in HCDs if they get it wrong.
     */

-   /* Check that the pipe's type matches the endpoint's type */
-   if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
-       dev_WARN(&dev->dev, "BOGUS urb xfer, pipe %x != type %x\n",
-           usb_pipetype(urb->pipe), pipetypes[xfertype]);
-
    /* Check against a simple/standard policy */
    allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | URB_DIR_MASK |
            URB_FREE_BUFFER);

Usually, one uses the patch program to apply patchfiles to the source code before compiling, but for this question, it might not be worth the bother. One can quickly just eyeball a patchfile and see the filename and the line numbers at the top and then open a text editor there (in this example, emacs +321 drivers/usb/core/urb.c). A quick glance is all it takes to know. (Minus signs mark lines that should be deleted and plus signs, added).

But, maybe it's a good idea to run patch

On the other hand, if one plans on recompiling Linux, it's not a bad idea to start from the distribution's default kernel. In that case, there's no reason not to try running patch. The program is smart enough to recognize if the patch was already applied and ask the operator if maybe they want to reverse it.

Example of running patch (previously unpatched)

Here is an example of what it looks like on a patch that was not in the default kernel:

$ patch -p1 < foo.patch
patching file drivers/usb/core/urb.c
Hunk #1 succeeded at 323 (offset 2 lines).
Hunk #2 succeeded at 440 (offset 2 lines).

If it succeeds, the distribution's default wasn't patched and needs to be recompiled. Fortunately, the Linux source code is now conveniently right there, with the patch applied.

Example of running patch (previously patched)

And here is what it would look like if the distribution's default kernel had already been patched:

$ patch -p1 < foo.patch
patching file drivers/usb/core/urb.c
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file drivers/usb/core/urb.c.rej

"Reversed or previously applied" means nothing more needs to be done as the default kernel was already patched.


Footnote ¹ Sorry for the bad pun, but don't blame me for it; that was the encouragement I was taught long, long ago by UNIX gurus wise in the ways of the Source. They said that when the Source is with you, you become more powerful than any proprietary vendor could ever imagine.

2

Linux is NOT Windows and thus "patches" are actually totally re-compiled/re-loaded from the base code after source code modifications and distributed as a package. Thus it is a bit difficult to know if some specific change has been incorporated into a binary without downloading the source and checking for the specific source code change.

Versions do not always help either. For example RedHat backports source code changes to older but supported versions of and application and re-released the package changing only the build number but not the version. So in RedHat, you cannot be totally sure if a change that was made by the developer releasing a new sub-version has not been backported to one of their re-released modules. This type of stuff drives me nuts.

Final though, remember there are multiple distributions of Linux with differing methods of package management, versioning and support.

Summary, to be absolutely sure a source code change has been implemented, you have to go to the source of the specific package for the specific distribution you are using.

0

In your specific case, your link is from year 2012 and talks about Ubuntu versions 11.10 and older.

The compat-wireless-3.0-rc4-1.tar.bz2 mentioned in there does not seem to be downloadable any more; and I think the contents would be essentially the wireless drivers of kernel version 3.0-rc4 adapted for installation to kernels older than that. Your Ubuntu 12.04 has kernel version 3.2 or newer; this package would be a downgrade for you. Kali 1.0.9 was released in 2014 and probably has even newer kernel version.

The channel -1 patch mentioned in your link modifies just 6 lines in <kernel source root>/net/wireless/chan.c file and does not change any kernel module firmware versions. As a result, there is no easy way to determine whether the patch is installed or not, other than downloading the kernel source package for your currently-installed kernel and looking at that source code file.

But I can go to https://www.kernel.org and browse the code there without downloading it. The oldest long-term supported kernel is 3.2.98 at this time: looking at its .../net/wireless/chan.c file, it seems the patch is not there: although the line numbers are about 30 lines off from what the patch has, the structure of the cfg80211_set_freq() function is still essentially the same, so one could in theory apply that patch to a "vanilla" 3.2. series kernel.

The next long-term kernel is version 3.16.53 at this time: when I look at its .../net/wireless/chan.c file, I see it has been totally overhauled: the function cfg80211_set_freq() that the patch modifies is simply no longer there. There is no way to install that channel -1 patch to this version as-is: you would have to understand the new code, find out if the patch is still applicable or not, and apply the equivalent version of the changes listed in the patch to appropriate new location(s) if necessary.

And that was just the "vanilla" standard kernels. Ubuntu or Kali may have applied further patches onto the standard kernels on their own.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .