{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":93659184,"defaultBranch":"fedora-39","name":"grub2","ownerLogin":"rhboot","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2017-06-07T16:59:47.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/29258823?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1718826952.0","currentOid":""},"activityList":{"items":[{"before":"6b8cb2092a6c18c8dcb088e5f784d643bf7d2e9b","after":"2b9a830f2208733d6a2260e21a86359e1de888d7","ref":"refs/heads/fedora-41","pushedAt":"2024-07-16T14:54:36.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"grub2-mkconfig: Ensure grub cfg stub is not overwritten\n\n/boot/efi/EFI/$os_name/grub.cfg contains a grub cfg stub\nthat should not be overwritten by grub2-mkconfig.\nEnsure that we prevent this from happening.\n\nSigned-off-by: Marta Lewandowska \nSigned-off-by: Nicolas Frayer ","shortMessageHtmlLink":"grub2-mkconfig: Ensure grub cfg stub is not overwritten"}},{"before":"1e90a46a570d6c49aeeb792a7d9188f0a36f6c85","after":"1d287bb66798e7ad5c3bf975049582aa4a8c2e39","ref":"refs/heads/rhel-9-main","pushedAt":"2024-07-16T13:55:05.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"chainloader: remove device path debug message\n\nRemove the debug message \"/EndEntire\" while using GRUB chainloader command.\n\nSigned-off-by: raravind \n(cherry picked from commit f75f5386b7a6a7cb2e10d30f817a3564c0a28dd7)","shortMessageHtmlLink":"chainloader: remove device path debug message"}},{"before":"01331d3a3c1c6134abccee0bc67f2683e3ffaf0e","after":"1e90a46a570d6c49aeeb792a7d9188f0a36f6c85","ref":"refs/heads/rhel-9-main","pushedAt":"2024-07-16T10:14:26.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"grub2-mkconfig: Ensure grub cfg stub is not overwritten\n\n/boot/efi/EFI/$os_name/grub.cfg contains a grub cfg stub\nthat should not be overwritten by grub2-mkconfig.\nEnsure that we prevent this from happening.\n\nSigned-off-by: Marta Lewandowska \nSigned-off-by: Nicolas Frayer ","shortMessageHtmlLink":"grub2-mkconfig: Ensure grub cfg stub is not overwritten"}},{"before":"d115afc1150dad507d80fcd41becedcb11870175","after":"01331d3a3c1c6134abccee0bc67f2683e3ffaf0e","ref":"refs/heads/rhel-9-main","pushedAt":"2024-07-12T14:21:33.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"cmd/search: Rework of CVE-2023-4001 fix\n\nThe initial fix implemented a new flag that forces the grub cfg\nstub to be located on the same disk as grub. This created several\nissues such as RAID machines not being able to boot as their\npartition names under grub were different from the partition where\ngrub is located. It also simply means that any machines with the\n/boot partition located on a disk other than the one containing grub\nwon't boot.\nThis commit denies booting if the grub cfg stub is located on a USB\ndrive with a duplicated UUID (UUID being the same as the partition\ncontaining the actual grub cfg stub)\n\nSigned-off-by: Nicolas Frayer ","shortMessageHtmlLink":"cmd/search: Rework of CVE-2023-4001 fix"}},{"before":"9b97ca6b5268001d263c5689ea50bb4edea2eab8","after":"6b8cb2092a6c18c8dcb088e5f784d643bf7d2e9b","ref":"refs/heads/fedora-41","pushedAt":"2024-07-02T14:56:09.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"kern/ieee1275/init: Add IEEE 1275 Radix support for KVM on Power\n\nThis patch adds support for Radix, Xive and Radix_gtse in Options\nvector5 which is required for KVM LPARs. KVM LPARs ONLY support\nRadix and not the Hash. Not enabling Radix on any PowerVM KVM LPARs\nwill result in boot failure.\n\nSigned-off-by: Avnish Chouhan \nReviewed-by: Daniel Kiper ","shortMessageHtmlLink":"kern/ieee1275/init: Add IEEE 1275 Radix support for KVM on Power"}},{"before":"86df79275d065d87f4de5c97e456973e8b4a649c","after":"b53ec06a1d6f22ffc1139cbfc0f292e4ca2da9cd","ref":"refs/heads/master","pushedAt":"2024-06-20T20:43:55.000Z","pushType":"push","commitsCount":20,"pusher":{"login":"vathpela","name":"Peter Jones","path":"/vathpela","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1063106?s=80&v=4"},"commit":{"message":"util/grub-mkrescue: Check existence of option arguments\n\nAs reported by Victoriia Egorova in bug 65880, grub-mkrescue does not\nverify that the expected argument of an option like -d or -k does really\nexist in argv. So, check the loop counter before incrementing it inside\nthe loop which copies argv to argp_argv. Issue an error message similar\nto what older versions of grub-mkrescue did with a missing argument,\ne.g. 2.02.\n\nFixes: https://savannah.gnu.org/bugs/index.php?65880\n\nSigned-off-by: Thomas Schmitt \nReviewed-by: Daniel Kiper ","shortMessageHtmlLink":"util/grub-mkrescue: Check existence of option arguments"}},{"before":null,"after":"b63ad1a0af4e9cd55bd5ce102dc3917436c822d4","ref":"refs/heads/rhel-10-main","pushedAt":"2024-06-19T19:55:52.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lsandov1","name":"Leonardo Sandoval","path":"/lsandov1","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/527807?s=80&v=4"},"commit":{"message":"fs/xfs: Fix XFS directory extent parsing\n\nThe XFS directory entry parsing code has never been completely correct\nfor extent based directories. The parser correctly handles the case\nwhere the directory is contained in a single extent, but then mistakenly\nassumes the data blocks for the multiple extent case are each identical\nto the single extent case. The difference in the format of the data\nblocks between the two cases is tiny enough that its gone unnoticed for\na very long time.\n\nA recent change introduced some additional bounds checking into the XFS\nparser. Like GRUB's existing parser, it is correct for the single extent\ncase but incorrect for the multiple extent case. When parsing a directory\nwith multiple extents, this new bounds checking is sometimes (but not\nalways) tripped and triggers an \"invalid XFS directory entry\" error. This\nprobably would have continued to go unnoticed but the /boot/grub/\ndirectory is large enough that it often has multiple extents.\n\nThe difference between the two cases is that when there are multiple\nextents, the data blocks do not contain a trailer nor do they contain\nany leaf information. That information is stored in a separate set of\nextents dedicated to just the leaf information. These extents come after\nthe directory entry extents and are not included in the inode size. So\nthe existing parser already ignores the leaf extents.\n\nThe only reason to read the trailer/leaf information at all is so that\nthe parser can avoid misinterpreting that data as directory entries. So\nthis updates the parser as follows:\n\nFor the single extent case the parser doesn't change much:\n1. Read the size of the leaf information from the trailer\n2. Set the end pointer for the parser to the start of the leaf\n information. (The previous bounds checking set the end pointer to the\n start of the trailer, so this is actually a small improvement.)\n3. Set the entries variable to the expected number of directory entries.\n\nFor the multiple extent case:\n1. Set the end pointer to the end of the block.\n2. Do not set up the entries variable. Figuring out how many entries are\n in each individual block is complex and does not seem worth it when\n it appears to be safe to just iterate over the entire block.\n\nThe bounds check itself was also dependent upon the faulty XFS parser\nbecause it accidentally used \"filename + length - 1\". Presumably this\nwas able to pass the fuzzer because in the old parser there was always\n8 bytes of slack space between the tail pointer and the actual end of\nthe block. Since this is no longer the case the bounds check needs to be\nupdated to \"filename + length + 1\" in order to prevent a regression in\nthe handling of corrupt fliesystems.\n\nNotes:\n* When there is only one extent there will only ever be one block. If\n more than one block is required then XFS will always switch to holding\n leaf information in a separate extent.\n* B-tree based directories seems to be parsed properly by the same code\n that handles multiple extents. This is unlikely to ever occur within\n /boot though because its only used when there are an extremely large\n number of directory entries.\n\nFixes: ef7850c75 (fs/xfs: Fix issues found while fuzzing the XFS filesystem)\nFixes: b2499b29c (Adds support for the XFS filesystem.)\nFixes: https://savannah.gnu.org/bugs/?64376\n\nSigned-off-by: Jon DeVree \nReviewed-by: Daniel Kiper \nTested-by: Sebastian Andrzej Siewior \nTested-by: Marta Lewandowska ","shortMessageHtmlLink":"fs/xfs: Fix XFS directory extent parsing"}},{"before":"56e58828cf3cd32ba4768779accc6655120c3136","after":"86df79275d065d87f4de5c97e456973e8b4a649c","ref":"refs/heads/master","pushedAt":"2024-06-06T16:44:05.000Z","pushType":"push","commitsCount":10,"pusher":{"login":"vathpela","name":"Peter Jones","path":"/vathpela","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1063106?s=80&v=4"},"commit":{"message":"commands/efi/tpm: Re-enable measurements on confidential computing platforms\n\nThe measurements for confidential computing has been introduced in the\ncommit 4c76565b6 (efi/tpm: Add EFI_CC_MEASUREMENT_PROTOCOL support).\nRecently the patch 30708dfe3 (tpm: Disable the tpm verifier if the TPM\ndevice is not present) has been introduced to optimize the memory usage\nwhen a TPM device is not available on platforms. This fix prevents the\ntpm module to be loaded on confidential computing platforms, e.g. Intel\nmachines with TDX enabled, where the TPM device is not available.\n\nIn this patch, we propose to load the tpm module for this use case by\ngeneralizing the tpm feature detection in order to cover CC platforms.\nBasically, we do it by detecting the availability of the\nEFI_CC_MEASUREMENT_PROTOCOL EFI protocol.\n\nFixes: https://savannah.gnu.org/bugs/?65821\nFixes: 30708dfe3 (tpm: Disable the tpm verifier if the TPM device is not present)\n\nSigned-off-by: Hector Cao \nReviewed-by: Daniel Kiper \nReviewed-by: Kuppuswamy Sathyanarayanan ","shortMessageHtmlLink":"commands/efi/tpm: Re-enable measurements on confidential computing pl…"}},{"before":"73464951026b1cc942176de392ccb333b49a1eae","after":"43a1e960e7b04605afde18300d733a21a5cf5860","ref":"refs/heads/fedora-40","pushedAt":"2024-05-29T09:41:47.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"cmd/search: Rework of CVE-2023-4001 fix\n\nThe initial fix implemented a new flag that forces the grub cfg\nstub to be located on the same disk as grub. This created several\nissues such as RAID machines not being able to boot as their\npartition names under grub were different from the partition where\ngrub is located. It also simply means that any machines with the\n/boot partition located on a disk other than the one containing grub\nwon't boot.\nThis commit denies booting if the grub cfg stub is located on a USB\ndrive with a duplicated UUID (UUID being the same as the partition\ncontaining the actual grub cfg stub)\n\nSigned-off-by: Nicolas Frayer ","shortMessageHtmlLink":"cmd/search: Rework of CVE-2023-4001 fix"}},{"before":"c1c228e9cc28b892888319d36f1a5b8489d2f527","after":"6cac608cbe05b95ec2903897ad19dbd0499ab60d","ref":"refs/heads/fedora-39","pushedAt":"2024-05-29T09:40:13.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"cmd/search: Rework of CVE-2023-4001 fix\n\nThe initial fix implemented a new flag that forces the grub cfg\nstub to be located on the same disk as grub. This created several\nissues such as RAID machines not being able to boot as their\npartition names under grub were different from the partition where\ngrub is located. It also simply means that any machines with the\n/boot partition located on a disk other than the one containing grub\nwon't boot.\nThis commit denies booting if the grub cfg stub is located on a USB\ndrive with a duplicated UUID (UUID being the same as the partition\ncontaining the actual grub cfg stub)\n\nSigned-off-by: Nicolas Frayer ","shortMessageHtmlLink":"cmd/search: Rework of CVE-2023-4001 fix"}},{"before":"8db5849a6ac1a6abdfc409c800b6420f8e390b4d","after":"9b97ca6b5268001d263c5689ea50bb4edea2eab8","ref":"refs/heads/fedora-41","pushedAt":"2024-05-28T17:24:24.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"lsandov1","name":"Leonardo Sandoval","path":"/lsandov1","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/527807?s=80&v=4"},"commit":{"message":"util/grub-mkconfig.in: revert mode to 644\n\nBy mistake, PR [1] changed the permission bits to 755 so revert it to\n644 again.\n\n[1] https://github.com/rhboot/grub2/pull/167\n\nSigned-off-by: Leo Sandoval ","shortMessageHtmlLink":"util/grub-mkconfig.in: revert mode to 644"}},{"before":"eb2b213dc48ba9bba2ef8e15dea54241e0a8fef3","after":"8db5849a6ac1a6abdfc409c800b6420f8e390b4d","ref":"refs/heads/fedora-41","pushedAt":"2024-05-28T17:09:54.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"lsandov1","name":"Leonardo Sandoval","path":"/lsandov1","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/527807?s=80&v=4"},"commit":{"message":"Set non-executable stack sections on EFI assembly files\n\nFor those manual assembly files created where no '.note.GNU-stack'\nsection is explicitly added, linker defaults it as executable and this\nis the reason that RHEL CI rpminspect & annocheck tests are\nfailing. The proposed change sets the corresponding GNU-stack\nsections otherwise CI detects the following security vulnerability\n\n $ annocheck annocheck --ignore-unknown --verbose --profile=el9 *.rpm 2>&1 | grep FAIL | grep stack\n (standard input):(standard input):Hardened: ./usr/lib/grub/x86_64-efi/kernel.exec: FAIL: gnu-stack test because .note.GNU-stack section has execute permission\n (standard input):(standard input):Hardened: ./usr/lib/grub/x86_64-efi/kernel.img: FAIL: gnu-stack test because .note.GNU-stack section has execute permission\n\nSigned-off-by: Leo Sandoval ","shortMessageHtmlLink":"Set non-executable stack sections on EFI assembly files"}},{"before":"602beb6a5feabf0348d0f0e92b61b77edb081b06","after":"73464951026b1cc942176de392ccb333b49a1eae","ref":"refs/heads/fedora-40","pushedAt":"2024-05-28T17:08:30.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"lsandov1","name":"Leonardo Sandoval","path":"/lsandov1","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/527807?s=80&v=4"},"commit":{"message":"grub-mkconfig.in: turn off executable owner bit\n\nStricker permissions are required on the grub.cfg file, resulting in\nat most 0600 owner's file permissions. This resolves conflicting\nrequirement permissions on grub2-pc package's grub2.cfg file.\n\nSigned-off-by: Leo Sandoval ","shortMessageHtmlLink":"grub-mkconfig.in: turn off executable owner bit"}},{"before":"4d4f137cf9ffc05081dc52b8b4142648ec56bf79","after":"d115afc1150dad507d80fcd41becedcb11870175","ref":"refs/heads/rhel-9-main","pushedAt":"2024-05-28T08:27:28.000Z","pushType":"pr_merge","commitsCount":16,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"grub2-mkconfig: Pass all boot params when used by anaconda\n\nPrevious patch makes it so that the machine can boot, but not all\nboot params are passed from /etc/default/grub to BLS snippets\nbecause /etc/default/grub gets written by anaconda during boot\nloader installation, long after grub rpms first got installed.\n\nSigned-off-by: Marta Lewandowska ","shortMessageHtmlLink":"grub2-mkconfig: Pass all boot params when used by anaconda"}},{"before":"d4bc15e8c071686756792f3e7ee314ddbf8a7fb7","after":"4d4f137cf9ffc05081dc52b8b4142648ec56bf79","ref":"refs/heads/rhel-9-main","pushedAt":"2024-05-23T18:47:48.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"grub-install on EFI if forced\n\nUEFI Secure Boot requires signed grub binaries to work, so grub-\ninstall should not be used. However, users who have Secure Boot\ndisabled and wish to use the command should not be prevented from\ndoing so if they invoke --force.\n\nfixes bz#1917213 / bz#2240994\n\nSigned-off-by: Marta Lewandowska ","shortMessageHtmlLink":"grub-install on EFI if forced"}},{"before":"386b59ddb42fa3f86ddfe557113b25c8fa16f88c","after":"56e58828cf3cd32ba4768779accc6655120c3136","ref":"refs/heads/master","pushedAt":"2024-05-23T16:44:23.000Z","pushType":"push","commitsCount":6,"pusher":{"login":"vathpela","name":"Peter Jones","path":"/vathpela","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1063106?s=80&v=4"},"commit":{"message":"fs/erofs: Add tests for EROFS in grub-fs-tester\n\nThis patch introduces three EROFS tests which cover compact, extended\nand chunk-based inodes respectively.\n\nSigned-off-by: Yifan Zhao \nReviewed-by: Glenn Washburn \nSigned-off-by: Gao Xiang \nReviewed-by: Daniel Kiper ","shortMessageHtmlLink":"fs/erofs: Add tests for EROFS in grub-fs-tester"}},{"before":"b60dfa5ba74640aa00c2394c2be7525fcc7343d8","after":"eb2b213dc48ba9bba2ef8e15dea54241e0a8fef3","ref":"refs/heads/fedora-41","pushedAt":"2024-05-23T15:32:32.000Z","pushType":"pr_merge","commitsCount":2,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"cmd/search: Rework of CVE-2023-4001 fix\n\nThe initial fix implemented a new flag that forces the grub cfg\nstub to be located on the same disk as grub. This created several\nissues such as RAID machines not being able to boot as their\npartition names under grub were different from the partition where\ngrub is located. It also simply means that any machines with the\n/boot partition located on a disk other than the one containing grub\nwon't boot.\nThis commit denies booting if the grub cfg stub is located on a USB\ndrive with a duplicated UUID (UUID being the same as the partition\ncontaining the actual grub cfg stub)\n\nSigned-off-by: Nicolas Frayer ","shortMessageHtmlLink":"cmd/search: Rework of CVE-2023-4001 fix"}},{"before":"423962ac7cb045dd70d491b5ebb51fab96af36dc","after":"b60dfa5ba74640aa00c2394c2be7525fcc7343d8","ref":"refs/heads/fedora-41","pushedAt":"2024-05-22T19:55:13.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"fs/xfs: Handle non-continuous data blocks in directory extents\n\nThe directory extent list does not have to be a continuous list of data\nblocks. When GRUB tries to read a non-existant member of the list,\ngrub_xfs_read_file() will return a block of zero'ed memory. Checking for\na zero'ed magic number is sufficient to skip this non-existant data block.\n\nPrior to commit 07318ee7e (fs/xfs: Fix XFS directory extent parsing)\nthis was handled as a subtle side effect of reading the (non-existant)\ntail data structure. Since the block was zero'ed the computation of the\nnumber of directory entries in the block would return 0 as well.\n\nFixes: 07318ee7e (fs/xfs: Fix XFS directory extent parsing)\nFixes: https://bugzilla.redhat.com/show_bug.cgi?id=2254370\n\nSigned-off-by: Jon DeVree \nReviewed-By: Vladimir Serbinenko \nReviewed-by: Daniel Kiper ","shortMessageHtmlLink":"fs/xfs: Handle non-continuous data blocks in directory extents"}},{"before":"3024d264161d668674678c58484d86e03ebd2d26","after":"b4d5005b1b96a80a269d0e9fb25cc5483969dd4f","ref":"refs/heads/rhel-8.8.0","pushedAt":"2024-05-17T10:10:52.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"util/grub-mkconfig.in: revert mode to 644\n\nBy mistake, PR [1] changed the permission bits to 755 so revert it to\n644 again.\n\n[1] https://github.com/rhboot/grub2/pull/165\n\nSigned-off-by: Leo Sandoval ","shortMessageHtmlLink":"util/grub-mkconfig.in: revert mode to 644"}},{"before":"2e8973a08ad737aacc3707df8db54d041dbe17e2","after":"3024d264161d668674678c58484d86e03ebd2d26","ref":"refs/heads/rhel-8.8.0","pushedAt":"2024-05-16T20:39:29.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"lsandov1","name":"Leonardo Sandoval","path":"/lsandov1","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/527807?s=80&v=4"},"commit":{"message":"grub-mkconfig.in: turn off executable owner bit\n\nStricker permissions are required on the grub.cfg file, resulting in\nat most 0600 owner's file permissions. This resolves conflicting\nrequirement permissions on grub2-pc package's grub2.cfg file.\n\nRelated: #RHEL-16478\nSigned-off-by: Leo Sandoval ","shortMessageHtmlLink":"grub-mkconfig.in: turn off executable owner bit"}},{"before":"c5b706d4116748a4d93ef5a7a70d01e5a972a28c","after":"423962ac7cb045dd70d491b5ebb51fab96af36dc","ref":"refs/heads/fedora-41","pushedAt":"2024-05-15T19:31:23.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"lsandov1","name":"Leonardo Sandoval","path":"/lsandov1","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/527807?s=80&v=4"},"commit":{"message":"grub-mkconfig.in: turn off executable owner bit\n\nStricker permissions are required on the grub.cfg file, resulting in\nat most 0600 owner's file permissions. This resolves conflicting\nrequirement permissions on grub2-pc package's grub2.cfg file.\n\nSigned-off-by: Leo Sandoval ","shortMessageHtmlLink":"grub-mkconfig.in: turn off executable owner bit"}},{"before":"32155dfbd3fd3f81b63893eb88f7582af8e5c600","after":"389e446ec06eb36f627384c00b4d82a2827e4483","ref":"refs/heads/rhel-9.4.0","pushedAt":"2024-05-14T08:48:07.000Z","pushType":"pr_merge","commitsCount":17,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"grub-install on EFI if forced\n\nUEFI Secure Boot requires signed grub binaries to work, so grub-\ninstall should not be used. However, users who have Secure Boot\ndisabled and wish to use the command should not be prevented from\ndoing so if they invoke --force.\n\nfixes bz#1917213 / bz#2240994\n\nSigned-off-by: Marta Lewandowska ","shortMessageHtmlLink":"grub-install on EFI if forced"}},{"before":"845ee6d41b62c336d293c6abc6d21e6ab10b48f4","after":"bcaa14535d8cc0a5e6eb5e1586804b446e2c3e17","ref":"refs/heads/rhel-9.3.0","pushedAt":"2024-05-13T18:10:07.000Z","pushType":"pr_merge","commitsCount":4,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"normal: Remove grub_env_set prefix in grub_try_normal_prefix\n\nCommit de735a453aa35 added a grub_env_set where the prefix contains\nthe arch name in the pathname. This create issues when trying to\nload modules using this prefix as the pathname contains a \"doubled\"\narch name in it (ie .../powerpc-ieee1275/powerpc-ieee1275/).\n\nSigned-off-by: Nicolas Frayer ","shortMessageHtmlLink":"normal: Remove grub_env_set prefix in grub_try_normal_prefix"}},{"before":"ef2e09bd2b84f27438360bc8b7cd270caf483b84","after":"ea975b89d3ecac48f7e8cfac4dda431c1d152ce8","ref":"refs/heads/fedora-38","pushedAt":"2024-05-13T16:36:51.000Z","pushType":"pr_merge","commitsCount":12,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"fs/xfs: Handle non-continuous data blocks in directory extents\n\nThe directory extent list does not have to be a continuous list of data\nblocks. When GRUB tries to read a non-existant member of the list,\ngrub_xfs_read_file() will return a block of zero'ed memory. Checking for\na zero'ed magic number is sufficient to skip this non-existant data block.\n\nPrior to commit 07318ee7e (fs/xfs: Fix XFS directory extent parsing)\nthis was handled as a subtle side effect of reading the (non-existant)\ntail data structure. Since the block was zero'ed the computation of the\nnumber of directory entries in the block would return 0 as well.\n\nFixes: 07318ee7e (fs/xfs: Fix XFS directory extent parsing)\nFixes: https://bugzilla.redhat.com/show_bug.cgi?id=2254370\n\nSigned-off-by: Jon DeVree \nReviewed-By: Vladimir Serbinenko \nReviewed-by: Daniel Kiper ","shortMessageHtmlLink":"fs/xfs: Handle non-continuous data blocks in directory extents"}},{"before":"c5b706d4116748a4d93ef5a7a70d01e5a972a28c","after":"602beb6a5feabf0348d0f0e92b61b77edb081b06","ref":"refs/heads/fedora-40","pushedAt":"2024-05-13T16:22:19.000Z","pushType":"pr_merge","commitsCount":3,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"fs/xfs: Handle non-continuous data blocks in directory extents\n\nThe directory extent list does not have to be a continuous list of data\nblocks. When GRUB tries to read a non-existant member of the list,\ngrub_xfs_read_file() will return a block of zero'ed memory. Checking for\na zero'ed magic number is sufficient to skip this non-existant data block.\n\nPrior to commit 07318ee7e (fs/xfs: Fix XFS directory extent parsing)\nthis was handled as a subtle side effect of reading the (non-existant)\ntail data structure. Since the block was zero'ed the computation of the\nnumber of directory entries in the block would return 0 as well.\n\nFixes: 07318ee7e (fs/xfs: Fix XFS directory extent parsing)\nFixes: https://bugzilla.redhat.com/show_bug.cgi?id=2254370\n\nSigned-off-by: Jon DeVree \nReviewed-By: Vladimir Serbinenko \nReviewed-by: Daniel Kiper ","shortMessageHtmlLink":"fs/xfs: Handle non-continuous data blocks in directory extents"}},{"before":"72b17102c157707acfffb01ae7694de6cf23eb5c","after":"c1c228e9cc28b892888319d36f1a5b8489d2f527","ref":"refs/heads/fedora-39","pushedAt":"2024-05-13T13:29:20.000Z","pushType":"pr_merge","commitsCount":12,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"fs/xfs: Handle non-continuous data blocks in directory extents\n\nThe directory extent list does not have to be a continuous list of data\nblocks. When GRUB tries to read a non-existant member of the list,\ngrub_xfs_read_file() will return a block of zero'ed memory. Checking for\na zero'ed magic number is sufficient to skip this non-existant data block.\n\nPrior to commit 07318ee7e (fs/xfs: Fix XFS directory extent parsing)\nthis was handled as a subtle side effect of reading the (non-existant)\ntail data structure. Since the block was zero'ed the computation of the\nnumber of directory entries in the block would return 0 as well.\n\nFixes: 07318ee7e (fs/xfs: Fix XFS directory extent parsing)\nFixes: https://bugzilla.redhat.com/show_bug.cgi?id=2254370\n\nSigned-off-by: Jon DeVree \nReviewed-By: Vladimir Serbinenko \nReviewed-by: Daniel Kiper ","shortMessageHtmlLink":"fs/xfs: Handle non-continuous data blocks in directory extents"}},{"before":"d4bc15e8c071686756792f3e7ee314ddbf8a7fb7","after":"32155dfbd3fd3f81b63893eb88f7582af8e5c600","ref":"refs/heads/rhel-9.4.0","pushedAt":"2024-05-13T13:13:09.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"Set non-executable stack sections on EFI assembly files\n\nFor those manual assembly files created where no '.note.GNU-stack'\nsection is explicitly added, linker defaults it as executable and this\nis the reason that RHEL CI rpminspect & annocheck tests are\nfailing. The proposed change sets the corresponding GNU-stack\nsections otherwise CI detects the following security vulnerability\n\n $ annocheck annocheck --ignore-unknown --verbose --profile=el9 *.rpm 2>&1 | grep FAIL | grep stack\n (standard input):(standard input):Hardened: ./usr/lib/grub/x86_64-efi/kernel.exec: FAIL: gnu-stack test because .note.GNU-stack section has execute permission\n (standard input):(standard input):Hardened: ./usr/lib/grub/x86_64-efi/kernel.img: FAIL: gnu-stack test because .note.GNU-stack section has execute permission\n\nSigned-off-by: Leo Sandoval ","shortMessageHtmlLink":"Set non-executable stack sections on EFI assembly files"}},{"before":"8719cc2040368d43ab2de0b6e1b850b2c9cfc5b7","after":"386b59ddb42fa3f86ddfe557113b25c8fa16f88c","ref":"refs/heads/master","pushedAt":"2024-05-09T18:43:59.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"vathpela","name":"Peter Jones","path":"/vathpela","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1063106?s=80&v=4"},"commit":{"message":"disk/cryptodisk: Allow user to retry failed passphrase\n\nGive the user a chance to re-enter their cryptodisk passphrase after a typo,\nrather than immediately failing (and likely dumping them into a GRUB shell).\n\nBy default, we allow 3 tries before giving up. A value in the\ncryptodisk_passphrase_tries environment variable will override this default.\n\nThe user can give up early by entering an empty passphrase, just as they\ncould before this patch.\n\nSigned-off-by: Forest \nReviewed-by: Daniel Kiper ","shortMessageHtmlLink":"disk/cryptodisk: Allow user to retry failed passphrase"}},{"before":null,"after":"d4bc15e8c071686756792f3e7ee314ddbf8a7fb7","ref":"refs/heads/rhel-9.4.0","pushedAt":"2024-05-06T16:41:14.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lsandov1","name":"Leonardo Sandoval","path":"/lsandov1","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/527807?s=80&v=4"},"commit":{"message":"tpm: Disable the tpm verifier if the TPM device is not present\n\nWhen the tpm module is loaded, the verifier reads entire file into\nmemory, measures it and uses verified content as a backing buffer for\nfile accesses. However, this process may result in high memory\nutilization for file operations, sometimes causing a system to run out\nof memory which may finally lead to boot failure. To address this issue,\namong others, the commit 887f98f0d (mm: Allow dynamically requesting\nadditional memory regions) have optimized memory management by\ndynamically allocating heap space to maximize memory usage and reduce\nthreat of memory exhaustion. But in some cases problems may still arise,\ne.g., when large ISO images are mounted using loopback or when dealing\nwith embedded systems with limited memory resources.\n\nUnfortunately current implementation of the tpm module doesn't allow\nelimination of the back buffer once it is loaded. Even if the TPM device\nis not present or it has been explicitly disabled. This may unnecessary\nallocate a lot memory. To solve this issue, a patch has been developed\nto detect the TPM status at module load and skip verifier registration\nif the device is missing or deactivated. This prevents allocation of\nmemory for the back buffer, avoiding wasting memory when no real measure\nboot functionality is performed. Disabling the TPM device in the system\ncan reduce memory usage in the GRUB. It is useful in scenarios where\nhigh memory utilization is a concern and measurements of loaded\nartifacts are not necessary.\n\nSigned-off-by: Michael Chang \nSigned-off-by: Stefan Berger \nReviewed-by: Daniel Kiper \n(cherry picked from commit 30708dfe3bebd62a5487437554da8a24253f519f)","shortMessageHtmlLink":"tpm: Disable the tpm verifier if the TPM device is not present"}},{"before":"de62df9a17e496d9478a05af2602c3ea6ebf7470","after":"845ee6d41b62c336d293c6abc6d21e6ab10b48f4","ref":"refs/heads/rhel-9.3.0","pushedAt":"2024-05-06T16:23:10.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"nfrayer","name":null,"path":"/nfrayer","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123334395?s=80&v=4"},"commit":{"message":"Set non-executable stack sections on EFI assembly files\n\nFor those manual assembly files created where no '.note.GNU-stack'\nsection is explicitly added, linker defaults it as executable and this\nis the reason that RHEL CI rpminspect & annocheck tests are\nfailing. The proposed change sets the corresponding GNU-stack\nsections otherwise CI detects the following security vulnerability\n\n $ annocheck annocheck --ignore-unknown --verbose --profile=el9 *.rpm 2>&1 | grep FAIL | grep stack\n (standard input):(standard input):Hardened: ./usr/lib/grub/x86_64-efi/kernel.exec: FAIL: gnu-stack test because .note.GNU-stack section has execute permission\n (standard input):(standard input):Hardened: ./usr/lib/grub/x86_64-efi/kernel.img: FAIL: gnu-stack test because .note.GNU-stack section has execute permission\n\nSigned-off-by: Leo Sandoval ","shortMessageHtmlLink":"Set non-executable stack sections on EFI assembly files"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEgOfaDQA","startCursor":null,"endCursor":null}},"title":"Activity · rhboot/grub2"}