In the Linux kernel, the following vulnerability has been resolved:
vt: fix unicode buffer corruption when deleting characters
The Linux kernel CVE team has assigned CVE-2024-35823 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051745-CVE-2024-35823-1e69@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
netrom: Fix data-races around sysctlnetbusyread
We need to protect the reader reading the sysctl value because the value can be changed concurrently.
In the Linux kernel, the following vulnerability has been resolved:
USB: usb-storage: Prevent divide-by-0 error in isd200atacommand
The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values in the ATA ID information to calculate cylinder and head values when creating a CDB for READ or WRITE commands. The calculation involves division and modulus operations, which will cause a crash if either of these values is 0. While this never happens with a genuine device, it could happen with a flawed or subversive emulation, as reported by the syzbot fuzzer.
Protect against this possibility by refusing to bind to the device if either the ATAIDHEADS or ATAIDSECTORS value in the device's ID information is 0. This requires isd200Initialization() to return a negative error code when initialization fails; currently it always returns 0 (even when there is an error).
In the Linux kernel, the following vulnerability has been resolved:
x86/mm: Disallow vsyscall page read for copyfromkernelnofault()
The Linux kernel CVE team has assigned CVE-2024-26906 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041746-CVE-2024-26906-bb35@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
tracing/trigger: Fix to return error if failed to alloc snapshot
Fix registersnapshottrigger() to return error code if it failed to allocate a snapshot instead of 0 (success). Unless that, it will register snapshot trigger without an error.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: set dormant flag on hook register failure
The Linux kernel CVE team has assigned CVE-2024-26835 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041714-CVE-2024-26835-083d@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
net: ice: Fix potential NULL pointer dereference in icebridgesetlink()
The function icebridgesetlink() may encounter a NULL pointer dereference if nlmsgfindattr() returns NULL and brspec is dereferenced subsequently in nlaforeachnested(). To address this issue, add a check to ensure that brspec is not NULL before proceeding with the nested attribute iteration.
In the Linux kernel, the following vulnerability has been resolved:
hvnetvsc: Register VF in netvscprobe if NETDEVICEREGISTER missed
If hvnetvsc driver is unloaded and reloaded, the NETDEVICEREGISTER handler cannot perform VF register successfully as the register call is received before netvscprobe is finished. This is because we register registernetdevicenotifier() very early( even before vmbusdriverregister()). To fix this, we try to register each such matching VF( if it is visible as a netdevice) at the end of netvscprobe.
In the Linux kernel, the following vulnerability has been resolved:
fbdev: sis: Error out if pixclock equals zero
The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error.
In sisfbcheckvar(), var->pixclock is used as a divisor to caculate drate before it is checked against zero. Fix this by checking it at the beginning.
This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8.
In the Linux kernel, the following vulnerability has been resolved:
mmc: mmci: stm32: fix DMA API overlapping mappings warning
Turning on CONFIGDMAAPIDEBUGSG results in the following warning:
DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 adddmaentry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: eventsfreezable mmcrescan Call trace: adddmaentry+0x234/0x2f4 debugdmamapsg+0x198/0x350 dmamapsgattrs+0xa0/0x110 dmamapsgattrs+0x10/0x2c sdmmcidmaprepdata+0x80/0xc0 mmciprepdata+0x38/0x84 mmcistartdata+0x108/0x2dc mmcirequest+0xe4/0x190 mmcstartrequest+0x68/0x140 mmcstartrequest+0x94/0xc0 mmcwaitforreq+0x70/0x100 mmcsendtuning+0x108/0x1ac sdmmcexecutetuning+0x14c/0x210 mmcexecutetuning+0x48/0xec mmcsdinituhscard.part.0+0x208/0x464 mmcsdinitcard+0x318/0x89c mmcattachsd+0xe4/0x180 mmcrescan+0x244/0x320
DMA API debug brings to light leaking dma-mappings as dmamapsg and dmaunmapsg are not correctly balanced.
If an error occurs in mmcicmdirq function, only mmcidmaerror function is called and as this API is not managed on stm32 variant, dmaunmapsg is never called in this error path.
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: fix a bug calling wakeupkswapd() with a wrong zone index
The Linux kernel CVE team has assigned CVE-2024-26783 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040458-CVE-2024-26783-68c8@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
netlink: Fix kernel-infoleak-after-free in skbdatagramiter
syzbot reported the following uninit-value access issue [1]:
netlinktofullskb() creates a new skb and puts the skb->data passed as a 1st arg of netlinktofullskb() onto new skb. The data size is specified as len and passed to skbputdata(). This len is based on skb->end that is not data offset but buffer offset. The skb->end contains data and tailroom. Since the tailroom is not initialized when the new skb created, KMSAN detects uninitialized memory area when copying the data.
This patch resolved this issue by correct the len from skb->end to skb->len, which is the actual data offset.
BUG: KMSAN: kernel-infoleak-after-free in instrumentcopytouser include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free in copytouseriter lib/ioviter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterateubuf include/linux/ioviter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterateandadvance2 include/linux/ioviter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterateandadvance include/linux/ioviter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in copytoiter+0x364/0x2520 lib/ioviter.c:186 instrumentcopytouser include/linux/instrumented.h:114 [inline] copytouseriter lib/ioviter.c:24 [inline] iterateubuf include/linux/ioviter.h:29 [inline] iterateandadvance2 include/linux/ioviter.h:245 [inline] iterateandadvance include/linux/ioviter.h:271 [inline] copytoiter+0x364/0x2520 lib/ioviter.c:186 copytoiter include/linux/uio.h:197 [inline] simplecopytoiter+0x68/0xa0 net/core/datagram.c:532 skbdatagramiter+0x123/0xdc0 net/core/datagram.c:420 skbcopydatagramiter+0x5c/0x200 net/core/datagram.c:546 skbcopydatagrammsg include/linux/skbuff.h:3960 [inline] packetrecvmsg+0xd9c/0x2000 net/packet/afpacket.c:3482 sockrecvmsgnosec net/socket.c:1044 [inline] sockrecvmsg net/socket.c:1066 [inline] sockreaditer+0x467/0x580 net/socket.c:1136 callreaditer include/linux/fs.h:2014 [inline] newsyncread fs/readwrite.c:389 [inline] vfsread+0x8f6/0xe00 fs/readwrite.c:470 ksysread+0x20f/0x4c0 fs/readwrite.c:613 dosysread fs/readwrite.c:623 [inline] sesysread fs/readwrite.c:621 [inline] x64sysread+0x93/0xd0 fs/readwrite.c:621 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b
Uninit was stored to memory at: skbputdata include/linux/skbuff.h:2622 [inline] netlinktofullskb net/netlink/afnetlink.c:181 [inline] netlinkdelivertapskb net/netlink/afnetlink.c:298 [inline] netlinkdelivertap+0x5be/0xc90 net/netlink/afnetlink.c:325 netlinkdelivertap net/netlink/afnetlink.c:338 [inline] netlinkdelivertapkernel net/netlink/afnetlink.c:347 [inline] netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x10f1/0x1250 net/netlink/afnetlink.c:1368 netlinksendmsg+0x1238/0x13d0 net/netlink/afnetlink.c:1910 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2584 syssendmsg+0x28d/0x3c0 net/socket.c:2638 syssendmsg net/socket.c:2667 [inline] dosyssendmsg net/socket.c:2676 [inline] sesyssendmsg net/socket.c:2674 [inline] x64syssendmsg+0x307/0x490 net/socket.c:2674 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b
Uninit was created at: freepagesprepare mm/pagealloc.c:1087 [inline] freeunrefpageprepare+0xb0/0xa40 mm/pagealloc.c:2347 freeunrefpagelist+0xeb/0x1100 mm/pagealloc.c:2533 releasepages+0x23d3/0x2410 mm/swap.c:1042 freepagesandswapcache+0xd9/0xf0 mm/swapstate.c:316 tlbbatchpages ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
inet: read sk->skfamily once in inetrecverror()
inetrecverror() is called without holding the socket lock.
IPv6 socket could mutate to IPv4 with IPV6ADDRFORM socket option and trigger a KCSAN warning.
In the Linux kernel, the following vulnerability has been resolved:
tracing: Ensure visibility when inserting an element into tracingmap
Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries:
$ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/rawsyscalls/sysenter/trigger cat /sys/kernel/debug/tracing/events/rawsyscalls/sysenter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc)
The warning looks as follows:
[ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracingmap.c:983 tracingmapsortentries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsiibft(E) iscsibootsysfs(E) rfkill(E) afpacket(E) nlsiso88591(E) nlscp437(E) vfat(E) fat(E) ena(E) tinypowerbutton(E) qemufwcfg(E) button(E) fuse(E) efipstore(E) iptables(E) xtables(E) xfs(E) libcrc32c(E) aesceblk(E) aescecipher(E) crct10difce(E) polyvalce(E) polyvalgeneric(E) ghashce(E) gf128mul(E) sm4cegcm(E) sm4ceccm(E) sm4ce(E) sm4cecipher(E) sm4(E) sm3ce(E) sm3(E) sha3ce(E) sha512ce(E) sha512arm64(E) sha2ce(E) sha256arm64(E) nvme(E) sha1ce(E) nvmecore(E) nvmeauth(E) t10pi(E) sg(E) scsimod(E) scsicommon(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppccpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracingmapsortentries+0x3e0/0x408 [ 2911.184667] lr : tracingmapsortentries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracingmapsortentries+0x3e0/0x408 [ 2911.195220] histshow+0x124/0x800 [ 2911.195692] seqreaditer+0x1d4/0x4e8 [ 2911.196193] seqread+0xe8/0x138 [ 2911.196638] vfsread+0xc8/0x300 [ 2911.197078] ksysread+0x70/0x108 [ 2911.197534] arm64sysread+0x24/0x38 [ 2911.198046] invokesyscall+0x78/0x108 [ 2911.198553] el0svccommon.constprop.0+0xd0/0xf8 [ 2911.199157] doel0svc+0x28/0x40 [ 2911.199613] el0svc+0x40/0x178 [ 2911.200048] el0t64synchandler+0x13c/0x158 [ 2911.200621] el0t64sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]---
The problem appears to be caused by CPU reordering of writes issued from tracingmapinsert().
The check for the presence of an element with a given key in this function is:
val = READONCE(entry->val); if (val && keysmatch(key, val->key, map->keysize)) ...
The write of a new entry is:
elt = getfreeelt(map); memcpy(elt->key, key, map->keysize); entry->val = elt;
The "memcpy(elt->key, key, map->keysize);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subse ---truncated---
A race condition was found in the Linux kernel's net/bluetooth in sniff{min,max}intervalset() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.
A race condition was found in the Linux kernel's net/bluetooth in {conn,adv}{min,max}intervalset() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix RELEASELOCKOWNER
The Linux kernel CVE team has assigned CVE-2024-26629 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/20240313140155.1913910-4-lee@kernel.org/T
A race condition was found in the Linux kernel's net/bluetooth device driver in conninfo{min,max}ageset() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.
A flaw in the Linux Kernel found in the Open vSwitch Kernel module.
The Netlink copy code in the ovs kernel module attempts to make an in-kernel copy of the actions required. That means that when recursive operations, like sample(), clone(), decttl(), etc include additional actions, the code pushes a new stack frame and recursively calls into the code block.
Unfortunately, OVS module doesn't validate the stack depth, and will push too many frames causing a stack overflow which can lead to crash.
Reference: https://lore.kernel.org/all/20240207132416.1488485-1-aconole@redhat.com/
In the Linux kernel, the following vulnerability has been resolved:
misc: lis3lv02di2c: Fix regulators getting en-/dis-abled twice on suspend/resume
The Linux kernel CVE team has assigned CVE-2024-35824 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051737-CVE-2024-35824-7302@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
net: veth: clear GRO when clearing XDP even when down
The Linux kernel CVE team has assigned CVE-2024-26803 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040404-CVE-2024-26803-9985@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Fix protection fault in iommufdtestsyzconviova
Syzkaller reported the following bug:
general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7] Call Trace: lockacquire lockacquire+0x1ce/0x4f0 downread+0x93/0x4a0 iommufdtestsyzconviova+0x56/0x1f0 iommufdtestaccessrw.isra.0+0x2ec/0x390 iommufdtest+0x1058/0x1e30 iommufdfopsioctl+0x381/0x510 vfsioctl dosysioctl sesysioctl x64sysioctl+0x170/0x1e0 dosyscallx64 dosyscall64+0x71/0x140
This is because the new iommufdaccesschangeioas() sets access->ioas to NULL during its process, so the lock might be gone in a concurrent racing context.
Fix this by doing the same access->ioas sanity as iommufdaccessrw() and iommufdaccesspinpages() functions do.
In the Linux kernel, the following vulnerability has been resolved:
xen/events: close evtchn after mapping cleanup
shutdownpirq and startuppirq are not taking the irqmappingupdatelock because they can't due to lock inversion. Both are called with the irqdesc->lock being taking. The lock order, however, is first irqmappingupdatelock and then irqdesc->lock.
This opens multiple races: - shutdownpirq can be interrupted by a function that allocates an event channel:
CPU0 CPU1 shutdownpirq { xenevtchnclose(e) startuppirq { EVTCHNOPbindpirq -> returns just freed evtchn e setevtchntoirq(e, irq) } xenirqinfocleanup() { setevtchntoirq(e, -1) } }
Assume here event channel e refers here to the same event channel number. After this race the evtchntoirq mapping for e is invalid (-1).
- startuppirq races with unbindfromirq in a similar way. Because startuppirq doesn't take irqmappingupdatelock it can grab the evtchn that unbindfromirq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchntoirq.
The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchntoirq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup.
On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvmesetupioqueues, pcifreeirq is called for every device which results in a call to shutdownpirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdownpirq and startuppirq are running potentially in parallel.
------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/eventsbase.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x8664 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvmeresetwork RIP: 0010:bindevtchntocpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? showtraceloglvl+0x1c1/0x2d9 ? showtraceloglvl+0x1c1/0x2d9 ? setaffinityirq+0xdc/0x1c0 ? diebody.cold+0x8/0xd ? die+0x2b/0x50 ? dotrap+0x90/0x110 ? bindevtchntocpu+0xdf/0xf0 ? doerrortrap+0x65/0x80 ? bindevtchntocpu+0xdf/0xf0 ? excinvalidop+0x4e/0x70 ? bindevtchntocpu+0xdf/0xf0 ? asmexcinvalidop+0x12/0x20 ? bindevtchntocpu+0xdf/0x ---truncated---
fs/proc: dotaskstat: use sig->statslock to gather the threads/children stats
A race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000getfrequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.
A race condition was found in the Linux kernel's media/dvb-core in dvbdmxwrite() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: ncm: Fix handling of zero block length packets
While connecting to a Linux host with CDCNCMNTBDEFSIZETX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present.
According to the NCM spec:
"If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent.
wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues.
wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB"
However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero.
In the Linux kernel, the following vulnerability has been resolved:
efi/capsule-loader: fix incorrect allocation size
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit physaddrt:
drivers/firmware/efi/capsule-loader.c: In function 'eficapsuleopen': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'physaddrt' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | capinfo->phys = kzalloc(sizeof(void ), GFPKERNEL); | ^
Use the correct type instead here.
In the Linux kernel, the following vulnerability has been resolved:
power: supply: bq27xxx-i2c: Do not free non existing IRQ
The bq27xxx i2c-client may not have an IRQ, in which case client->irq will be 0. bq27xxxbatteryi2cprobe() already has an if (client->irq) check wrapping the requestthreadedirq().
But bq27xxxbatteryi2cremove() unconditionally calls freeirq(client->irq) leading to:
[ 190.310742] ------------[ cut here ]------------ [ 190.310843] Trying to free already-free IRQ 0 [ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 freeirq+0x1b8/0x310
Followed by a backtrace when unbinding the driver. Add an if (client->irq) to bq27xxxbatteryi2cremove() mirroring probe() to fix this.
In the Linux kernel, the following vulnerability has been resolved:
scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlrlock"
This reverts commit 1a1975551943f681772720f639ff42fbaa746212.
This commit causes interrupts to be lost for FCoE devices, since it changed sping locks from "bh" to "irqsave".
Instead, a work queue should be used, and will be addressed in a separate commit.