The Linux Kernel, the operating system core itself.
Security Fix(es):
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47084)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47085)
In the Linux kernel, the following vulnerability has been resolved:
mm/hwpoison: clear MFCOUNTINCREASED before retrying getanypage()
Hulk Robot reported a panic in putpagetestzero() when testing madvise() with MADVSOFTOFFLINE. The BUG() is triggered when retrying getanypage(). This is because we keep MFCOUNTINCREASED flag in second try but the refcnt is not increased.
page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
------------[ cut here ]------------
kernel BUG at include/linux/mm.h:737!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 5 PID: 2135 Comm: sshd Tainted: G B 5.16.0-rc6-dirty #373
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: release_pages+0x53f/0x840
Call Trace:
free_pages_and_swap_cache+0x64/0x80
tlb_flush_mmu+0x6f/0x220
unmap_page_range+0xe6c/0x12c0
unmap_single_vma+0x90/0x170
unmap_vmas+0xc4/0x180
exit_mmap+0xde/0x3a0
mmput+0xa3/0x250
do_exit+0x564/0x1470
do_group_exit+0x3b/0x100
__do_sys_exit_group+0x13/0x20
__x64_sys_exit_group+0x16/0x20
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Modules linked in:
---[ end trace e99579b570fe0649 ]---
RIP: 0010:release_pages+0x53f/0x840(CVE-2021-47090)
In the Linux kernel, the following vulnerability has been resolved:
ipmi: Fix UAF when uninstall ipmisi and ipmimsghandler module
Hi,
When testing install and uninstall of ipmisi.ko and ipmimsghandler.ko, the system crashed.
The log as follows: [ 141.087026] BUG: unable to handle kernel paging request at ffffffffc09b3a5a [ 141.087241] PGD 8fe4c0d067 P4D 8fe4c0d067 PUD 8fe4c0f067 PMD 103ad89067 PTE 0 [ 141.087464] Oops: 0010 [#1] SMP NOPTI [ 141.087580] CPU: 67 PID: 668 Comm: kworker/67:1 Kdump: loaded Not tainted 4.18.0.x8664 #47 [ 141.088009] Workqueue: events 0xffffffffc09b3a40 [ 141.088009] RIP: 0010:0xffffffffc09b3a5a [ 141.088009] Code: Bad RIP value. [ 141.088009] RSP: 0018:ffffb9094e2c3e88 EFLAGS: 00010246 [ 141.088009] RAX: 0000000000000000 RBX: ffff9abfdb1f04a0 RCX: 0000000000000000 [ 141.088009] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 [ 141.088009] RBP: 0000000000000000 R08: ffff9abfffee3cb8 R09: 00000000000002e1 [ 141.088009] R10: ffffb9094cb73d90 R11: 00000000000f4240 R12: ffff9abfffee8700 [ 141.088009] R13: 0000000000000000 R14: ffff9abfdb1f04a0 R15: ffff9abfdb1f04a8 [ 141.088009] FS: 0000000000000000(0000) GS:ffff9abfffec0000(0000) knlGS:0000000000000000 [ 141.088009] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 141.088009] CR2: ffffffffc09b3a30 CR3: 0000008fe4c0a001 CR4: 00000000007606e0 [ 141.088009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 141.088009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 141.088009] PKRU: 55555554 [ 141.088009] Call Trace: [ 141.088009] ? processonework+0x195/0x390 [ 141.088009] ? workerthread+0x30/0x390 [ 141.088009] ? processonework+0x390/0x390 [ 141.088009] ? kthread+0x10d/0x130 [ 141.088009] ? kthreadflushworkfn+0x10/0x10 [ 141.088009] ? retfromfork+0x35/0x40] BUG: unable to handle kernel paging request at ffffffffc0b28a5a [ 200.223240] PGD 97fe00d067 P4D 97fe00d067 PUD 97fe00f067 PMD a580cbf067 PTE 0 [ 200.223464] Oops: 0010 [#1] SMP NOPTI [ 200.223579] CPU: 63 PID: 664 Comm: kworker/63:1 Kdump: loaded Not tainted 4.18.0.x8664 #46 [ 200.224008] Workqueue: events 0xffffffffc0b28a40 [ 200.224008] RIP: 0010:0xffffffffc0b28a5a [ 200.224008] Code: Bad RIP value. [ 200.224008] RSP: 0018:ffffbf3c8e2a3e88 EFLAGS: 00010246 [ 200.224008] RAX: 0000000000000000 RBX: ffffa0799ad6bca0 RCX: 0000000000000000 [ 200.224008] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 [ 200.224008] RBP: 0000000000000000 R08: ffff9fe43fde3cb8 R09: 00000000000000d5 [ 200.224008] R10: ffffbf3c8cb53d90 R11: 00000000000f4240 R12: ffff9fe43fde8700 [ 200.224008] R13: 0000000000000000 R14: ffffa0799ad6bca0 R15: ffffa0799ad6bca8 [ 200.224008] FS: 0000000000000000(0000) GS:ffff9fe43fdc0000(0000) knlGS:0000000000000000 [ 200.224008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 200.224008] CR2: ffffffffc0b28a30 CR3: 00000097fe00a002 CR4: 00000000007606e0 [ 200.224008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 200.224008] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 200.224008] PKRU: 55555554 [ 200.224008] Call Trace: [ 200.224008] ? processonework+0x195/0x390 [ 200.224008] ? workerthread+0x30/0x390 [ 200.224008] ? processonework+0x390/0x390 [ 200.224008] ? kthread+0x10d/0x130 [ 200.224008] ? kthreadflushworkfn+0x10/0x10 [ 200.224008] ? retfromfork+0x35/0x40 [ 200.224008] kernel fault(0x1) notification starting on CPU 63 [ 200.224008] kernel fault(0x1) notification finished on CPU 63 [ 200.224008] CR2: ffffffffc0b28a5a [ 200.224008] ---[ end trace c82a412d93f57412 ]---
The reason is as follows: T1: rmmod ipmisi. ->ipmiunregistersmi() -> ipmibmcunregister() -> _ipmibmcunregister() -> krefput(&bmc->usecount, cleanupbmcdevice); -> schedulework(&bmc->remove_work);
T2: rmmod ipmi_msghandl ---truncated---(CVE-2021-47100)
In the Linux kernel, the following vulnerability has been resolved:
net: caif: fix memory leak in cfusbldevicenotify
In case of caifenrolldev() fail, allocated link_support won't be assigned to the corresponding structure. So simply free allocated pointer in case of error.(CVE-2021-47121)
In the Linux kernel, the following vulnerability has been resolved:
net: fujitsu: fix potential null-ptr-deref
In fmvj18xgethwinfo(), if ioremap fails there will be NULL pointer deref. To fix this, check the return value of ioremap and return -1 to the caller in case of failure.(CVE-2021-47149)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix link down processing to address NULL pointer dereference
If an FC link down transition while PLOGIs are outstanding to fabric well known addresses, outstanding ABTS requests may result in a NULL pointer dereference. Driver unload requests may hang with repeated "2878" log messages.
The Link down processing results in ABTS requests for outstanding ELS requests. The Abort WQEs are sent for the ELSs before the driver had set the link state to down. Thus the driver is sending the Abort with the expectation that an ABTS will be sent on the wire. The Abort request is stalled waiting for the link to come up. In some conditions the driver may auto-complete the ELSs thus if the link does come up, the Abort completions may reference an invalid structure.
Fix by ensuring that Abort set the flag to avoid link traffic if issued due to conditions where the link failed.(CVE-2021-47183)
In the Linux kernel, the following vulnerability has been resolved:
cfg80211: call cfg80211stopap when switch from P2P_GO type
If the userspace tools switch from NL80211IFTYPEP2PGO to NL80211IFTYPEADHOC via sendmsg(NL80211CMDSETINTERFACE), it does not call the cleanup cfg80211stopap(), this leads to the initialization of in-use data. For example, this path re-init the sdata->assignedchanctxlist while it is still an element of assignedvifs list, and makes that linked list corrupt.(CVE-2021-47194)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tipd: Remove WARNON in tps6598xblock_read
Calling tps6598xblockread with a higher than allowed len can be handled by just returning an error. There's no need to crash systems with panic-on-warn enabled.(CVE-2021-47210)
In the Linux kernel, the following vulnerability has been resolved:
pstore/ram: Fix crash when setting number of cpus to an odd number
When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zonesize addr of zone2 = BASE + zonesize*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va.
So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug.(CVE-2023-52619)
A race condition was found in the Linux kernel's bluetooth device driver in {min,max}keysize_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
(CVE-2024-24860)
In the Linux kernel, the following vulnerability has been resolved:
ip6tunnel: fix NEXTHDRFRAGMENT handling in ip6tnlparsetlvenc_lim()
syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.
Reading frag_off can only be done if we pulled enough bytes to skb->head. Currently we might access garbage.
[1] BUG: KMSAN: uninit-value in ip6tnlparsetlvenclim+0x94f/0xbb0 ip6tnlparsetlvenclim+0x94f/0xbb0 ipxip6tnlxmit net/ipv6/ip6tunnel.c:1326 [inline] ip6tnlstartxmit+0xab2/0x1a70 net/ipv6/ip6tunnel.c:1432 netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x247/0xa10 net/core/dev.c:3564 _devqueuexmit+0x33b8/0x5130 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] neighconnectedoutput+0x569/0x660 net/core/neighbour.c:1592 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x23a9/0x2b30 net/ipv6/ip6output.c:137 ip6finishoutput+0x855/0x12b0 net/ipv6/ip6output.c:222 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x323/0x610 net/ipv6/ip6output.c:243 dstoutput include/net/dst.h:451 [inline] ip6localout+0xe9/0x140 net/ipv6/outputcore.c:155 ip6sendskb net/ipv6/ip6output.c:1952 [inline] ip6pushpendingframes+0x1f9/0x560 net/ipv6/ip6output.c:1972 rawv6pushpendingframes+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inetsendmsg+0x105/0x190 net/ipv4/afinet.c:847 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 entrySYSCALL64after_hwframe+0x63/0x6b
Uninit was created at: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x5c9/0x970 mm/slub.c:3517 _dokmallocnode mm/slabcommon.c:1006 [inline] _kmallocnodetrackcaller+0x118/0x3c0 mm/slabcommon.c:1027 kmallocreserve+0x249/0x4a0 net/core/skbuff.c:582 pskbexpandhead+0x226/0x1a00 net/core/skbuff.c:2098 _pskbpulltail+0x13b/0x2310 net/core/skbuff.c:2655 pskbmaypullreason include/linux/skbuff.h:2673 [inline] pskbmaypull include/linux/skbuff.h:2681 [inline] ip6tnlparsetlvenclim+0x901/0xbb0 net/ipv6/ip6tunnel.c:408 ipxip6tnlxmit net/ipv6/ip6tunnel.c:1326 [inline] ip6tnlstartxmit+0xab2/0x1a70 net/ipv6/ip6tunnel.c:1432 _netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x247/0xa10 net/core/dev.c:3564 _devqueuexmit+0x33b8/0x5130 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] neighconnectedoutput+0x569/0x660 net/core/neighbour.c:1592 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x23a9/0x2b30 net/ipv6/ip6output.c:137 ip6finishoutput+0x855/0x12b0 net/ipv6/ip6output.c:222 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x323/0x610 net/ipv6/ip6output.c:243 dstoutput include/net/dst.h:451 [inline] ip6localout+0xe9/0x140 net/ipv6/outputcore.c:155 ip6sendskb net/ipv6/ip6output.c:1952 [inline] ip6pushpendingframes+0x1f9/0x560 net/ipv6/ip6output.c:1972 rawv6pushpendingframes+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inetsendmsg+0x105/0x190 net/ipv4/afinet.c:847 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] _dosys_sendms ---truncated---(CVE-2024-26633)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't abort filesystem when attempting to snapshot deleted subvolume
If the source file descriptor to the snapshot ioctl refers to a deleted subvolume, we get the following abort:
BTRFS: Transaction aborted (error -2) WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 creatependingsnapshot+0x1040/0x1190 [btrfs] Modules linked in: pataacpi btrfs atapiix libata scsimod virtionet blake2bgeneric xor netfailover virtiorng failover scsicommon rngcore raid6pq libcrc32c CPU: 0 PID: 833 Comm: tsnapshotdele Not tainted 6.7.0-rc6 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:creatependingsnapshot+0x1040/0x1190 [btrfs] RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027 RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840 RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998 R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80 FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0 Call Trace: <TASK> ? creatependingsnapshot+0x1040/0x1190 [btrfs] ? _warn+0x81/0x130 ? creatependingsnapshot+0x1040/0x1190 [btrfs] ? reportbug+0x171/0x1a0 ? handlebug+0x3a/0x70 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? creatependingsnapshot+0x1040/0x1190 [btrfs] ? creatependingsnapshot+0x1040/0x1190 [btrfs] creatependingsnapshots+0x92/0xc0 [btrfs] btrfscommittransaction+0x66b/0xf40 [btrfs] btrfsmksubvol+0x301/0x4d0 [btrfs] btrfsmksnapshot+0x80/0xb0 [btrfs] _btrfsioctlsnapcreate+0x1c2/0x1d0 [btrfs] btrfsioctlsnapcreatev2+0xc4/0x150 [btrfs] btrfsioctl+0x8a6/0x2650 [btrfs] ? kmemcachefree+0x22/0x340 ? dosysopenat2+0x97/0xe0 _x64sysioctl+0x97/0xd0 dosyscall64+0x46/0xf0 entrySYSCALL64afterhwframe+0x6e/0x76 RIP: 0033:0x7fe20abe83af RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58 </TASK> ---[ end trace 0000000000000000 ]--- BTRFS: error (device vdc: state A) in creatependingsnapshot:1875: errno=-2 No such entry BTRFS info (device vdc: state EA): forced readonly BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction. BTRFS: error (device vdc: state EA) in cleanuptransaction:2055: errno=-2 No such entry
This happens because creatependingsnapshot() initializes the new root item as a copy of the source root item. This includes the refs field, which is 0 for a deleted subvolume. The call to btrfsinsertroot() therefore inserts a root with refs == 0. btrfsgetnewfsroot() then finds the root and returns -ENOENT if refs == 0, which causes creatependingsnapshot() to abort.
Fix it by checking the source root's refs before attempting the snapshot, but after locking subvol_sem to avoid racing with deletion.(CVE-2024-26644)
In the Linux kernel, the following vulnerability has been resolved:
ARM: ep93xx: Add terminator to gpiodlookuptable
Without the terminator, if a conid is passed to gpiofind() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops.(CVE-2024-26751)
In the Linux kernel, the following vulnerability has been resolved:
fs/aio: Restrict kiocbsetcancel_fn() to I/O submitted via libaio
If kiocbsetcancelfn() is called for I/O submitted via iouring, the following kernel warning appears:
WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocbsetcancelfn+0x9c/0xa8 Call trace: kiocbsetcancelfn+0x9c/0xa8 ffsepfilereaditer+0x144/0x1d0 ioread+0x19c/0x498 ioissuesqe+0x118/0x27c iosubmitsqes+0x25c/0x5fc _arm64sysiouringenter+0x104/0xab0 invokesyscall+0x58/0x11c el0svccommon+0xb4/0xf4 doel0svc+0x2c/0xb0 el0svc+0x2c/0xa4 el0t64synchandler+0x68/0xb4 el0t64sync+0x1a4/0x1a8
Fix this by setting the IOCBAIORW flag for read and write I/O that is submitted by libaio.(CVE-2024-26764)
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid allocating blocks from corrupted group in ext4mbfindbygoal()
Places the logic for checking if the group's block bitmap is corrupt under the protection of the group lock to avoid allocating blocks from the group with a corrupted block bitmap.(CVE-2024-26772)
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid allocating blocks from corrupted group in ext4mbtrybestfound()
Determine if the group block bitmap is corrupted before using acbex in ext4mbtrybestfound() to avoid allocating blocks from a group with a corrupted block bitmap in the following concurrency and making the situation worse.
ext4mbregularallocator ext4lockgroup(sb, group) ext4mbgoodgroup // check if the group bbitmap is corrupted ext4mbcomplexscangroup // Scan group gets acbex but doesn't use it ext4unlockgroup(sb, group) ext4markgroupbitmapcorrupted(group) // The block bitmap was corrupted during // the group unlock gap. ext4mbtrybestfound ext4lockgroup(ac->acsb, group) ext4mbusebestfound mbmark_used // Allocating blocks in block bitmap corrupted group(CVE-2024-26773)
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.(CVE-2024-26777)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: savage: 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.
Although pixclock is checked in savagefbdecodevar(), but it is not checked properly in savagefbprobe(). Fix this by checking whether pixclock is zero in the function savagefbcheck_var() before info->var.pixclock is used as the divisor.
This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8.(CVE-2024-26778)
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Lock external INTx masking ops
Mask operations through config space changes to DisINTx may race INTx configuration changes via ioctl. Create wrappers that add locking for paths outside of the core interrupt code.
In particular, irqtype is updated holding igate, therefore testing isintx() requires holding igate. For example clearing DisINTx from config space can otherwise race changes of the interrupt configuration.
This aligns interfaces which may trigger the INTx eventfd into two camps, one side serialized by igate and the other only enabled while INTx is configured. A subsequent patch introduces synchronization for the latter flows.(CVE-2024-26810)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix hashtab overflow check on 32-bit arches
The hashtab code relies on rounduppowoftwo() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAPHASH type, which contains the same check, copied from the hashtab code. So apply the same fix to hashtab, by moving the overflow check to before the roundup.(CVE-2024-26884)
In the Linux kernel, the following vulnerability has been resolved:
aoe: fix the potential use-after-free problem in aoecmdcfgpkts
This patch is against CVE-2023-6270. The description of cve is:
A flaw was found in the ATA over Ethernet (AoE) driver in the Linux
kernel. The aoecmdcfgpkts() function improperly updates the refcnt on
struct net_device
, and a use-after-free can be triggered by racing
between the free on the struct and the access through the skbtxq
global queue. This could lead to a denial of service condition or
potential code execution.
In aoecmdcfgpkts(), it always calls devput(ifp) when skb initial code is finished. But the netdevice ifp will still be used in later tx()->devqueuexmit() in kthread. Which means that the devput(ifp) should NOT be called in the success path of skb initial code in aoecmdcfgpkts(). Otherwise tx() may run into use-after-free because the netdevice is freed.
This patch removed the devput(ifp) in the success path in aoecmdcfgpkts(), and added devput() after skb xmit in tx().(CVE-2024-26898)
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Disable auto-enable of exclusive INTx IRQ
Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in request_irq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio.
Instead, invert the logic using IRQFNOAUTOEN such that exclusive INTx is never auto-enabled, then unmask as required.(CVE-2024-27437)
{ "severity": "High" }
{ "x86_64": [ "kernel-devel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "kernel-tools-devel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "bpftool-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "bpftool-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "kernel-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "kernel-tools-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "python2-perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "kernel-tools-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "python3-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "python3-perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "kernel-source-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "kernel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "python2-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm", "kernel-debugsource-4.19.90-2405.1.0.0248.oe1.x86_64.rpm" ], "src": [ "kernel-4.19.90-2405.1.0.0248.oe1.src.rpm" ], "aarch64": [ "python3-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "kernel-devel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "bpftool-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "kernel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "python2-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "kernel-debugsource-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "python3-perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "kernel-source-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "kernel-tools-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "bpftool-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "python2-perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "kernel-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "kernel-tools-devel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "kernel-tools-4.19.90-2405.1.0.0248.oe1.aarch64.rpm", "perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm" ] }